29 апреля (вт) в 19:00 (мск) пройдёт вебинар на тему «Всё о найме СА в 2025 году: Интервью с рекрутером»

Мы пригласили практикующего рекрутера обсудить самые актуальные вопросы найма системных аналитиков в 2025 году:
— Как изменился подбор с 2022 года?
— На что HR в первую очередь обращает внимание, просматривая резюме аналитика?
— Сопроводительное письмо при отклике, насколько оно важно?
— Какие навыки и знания сегодня наиболее востребованы у СА?
— Нужно ли системному аналитику знать основы программирования, чтобы успешно пройти собеседование?
— Как подготовиться к HR интервью?
— Какие распространенные ошибки совершают кандидаты-аналитики на HR интервью?
— Как рекрутер рекомендует подходить к выполнению тестового задания на собеседовании?
— Как рекрутер рекомендует обсуждать свои зарплатные ожидания на собеседованиях?
— Какие вопросы стоит задать рекрутеру на собеседовании?
— Что ректутер особенно ценит в кандидатах-аналитиках помимо технических навыков?
— Какой совет можно дать специалистам, которые хотят перейти в системную аналитику из другой сферы?
— Как HRы относятся к кандидату, если замечают накрутку возраста, опыта, навыков?
— Почему рекрутер берет большие паузы между этапами процесса подбора?

■ Вебинар будет полезен:
Не системным аналитикам, которые
— хотят сменить профессию, но не уверены в том, что смогут осилить конкуренцию на рынке
Системным аналитикам, которые
— хотят подготовиться к интервью
— стремятся быть в курсе актуальных требований к кандидатам на позицию СА уровня Junior и Middle

■ Приглашённый рекрутер — Пирожкова Вероника
— Имеет опыт работы в стартапах, «Газпром нефть», VK
— Занималась подбором Python‑разработчиков, data‑scientists, тестировщиков, Solution‑, Enterprise‑ и Software‑architect, DevOps, Data Scientist
— Сопровождала многоэтапные воронки (до 5 интервью от screening до оффера)
— Участвовала в формировании процесса подбора новых сотрудников
— В настоящее время подбирает аналитиков (web‑, системных, бизнес‑, full‑stack); в среднем — 20 % BA / 80 % SA

■ Ведущая вебинара — Козлова Наталья, ведущая курсов SE, эксперт в бизнес- и системном анализе
За последнее время прошла 24 скрининга с HR, 18 техсобесов или собесов с командой, получила 3 оффера и 4 отказа.

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

Регистрация обязательна
❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.

#вебинар@systems_education

29 апреля (вт) в 19:00 (мск) пройдёт вебинар на тему «Всё о найме СА в 2025 году: Интервью с рекрутером»

Мы пригласили практикующего рекрутера обсудить самые актуальные вопросы найма системных аналитиков в 2025 году:
— Как изменился подбор с 2022 года?
— На что HR в первую очередь обращает внимание, просматривая резюме аналитика?
— Сопроводительное письмо при отклике, насколько оно важно?
— Какие навыки и знания сегодня наиболее востребованы у СА?
— Нужно ли системному аналитику знать основы программирования, чтобы успешно пройти собеседование?
— Как подготовиться к HR интервью?
— Какие распространенные ошибки совершают кандидаты-аналитики на HR интервью?
— Как рекрутер рекомендует подходить к выполнению тестового задания на собеседовании?
— Как рекрутер рекомендует обсуждать свои зарплатные ожидания на собеседованиях?
— Какие вопросы стоит задать рекрутеру на собеседовании?
— Что ректутер особенно ценит в кандидатах-аналитиках помимо технических навыков?
— Какой совет можно дать специалистам, которые хотят перейти в системную аналитику из другой сферы?
— Как HRы относятся к кандидату, если замечают накрутку возраста, опыта, навыков?
— Почему рекрутер берет большие паузы между этапами процесса подбора?

Вебинар будет полезен:
Не системным аналитикам
— которые хотят сменить профессию, но не уверены в том, что смогут осилить конкуренцию на рынке

Системным аналитикам, которые
— хотят подготовиться к интервью
— стремятся быть в курсе актуальных требований к кандидатам на позицию СА уровня Junior и Middle

■ Приглашённый рекрутер — Пирожкова Вероника
Подробнее о е
1. Стартап
— Подбирала Python‑разработчиков, data‑scientists, тестировщиков и коммерческий персонал
— Участвовала в формировании процесса подбора новых сотрудников. С нуля создали чек листы для тех и HR интервью.

2. «Газпром нефть»
— Вела подбор на позиции Solution‑, Enterprise‑ и Software‑architect, DevOps, Data Scientist
— Сопровождала многоэтапные воронки (до 5 интервью от screening до оффера)

3. VK
— Фокус на Java‑разработчиках и SRE/DevOps‑инженерах

4. В настоящее время
— Подбираю аналитиков (web‑, системных, бизнес‑, full‑stack); в среднем — 20 % BA / 80 % SA

Воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования»

Аналитик использует диаграммы последовательности для описания межсистемного или внутрисистемного взаимодействия. Схемы UML sequence помогают разработчикам определить методы классов, вызовы и ответы веб-API.

🔹Когда старт?
21 мая (ср)

🔹Цель обучения
— Научиться строить sequence диаграммы, их читать и использовать для проектирования поведения систем.

🔹Это обучение для:
— системных аналитиков
— проектировщикам информационных систем
— разработчиков
— всех, кто интересуется UML

🔹Вы узнаете:
— Что такое UML
— Что такое диаграмма последовательности UML
— Как строить sequence диаграмму на кейсе интернет-магазина

Регистрация

#воркшоп@systems_education #UML@systems_education #архитектура@systems_education

Event Storming vs Domain-Driven Design: в чём отличие и как они взаимодействуют?

Когда речь заходит об Event Storming, опытные команды представляют большую доску, цветные стикеры и активную дискуссию о событиях системы. А Domain-Driven Design (DDD) сразу ассоциируется с такими понятиями, как «ограниченный контекст» , «единый язык» и сложные предметные области. Эти подходы часто упоминают вместе — и не случайно.

СРАВНЕНИЕ КЛЮЧЕВЫХ АСПЕКТОВ

👀 Фокус
— Event Storming: Быстрое и визуальное выявление событий, триггеров и участников процесса
— DDD: Стратегическое проектирование архитектуры и кода с учётом всех нюансов предметной области

🛠 Способ применения
— Event Storming: Короткие, интенсивные воркшопы, на которых команда «раскрывает» бизнес-процессы, идентифицирует проблемы и точки роста
— DDD: Долгосрочный подход к разработке, в котором вся команда придерживается общих принципов и паттернов, ориентируясь на бизнес-логику и контексты

🎯 Результат
— Event Storming: Общая динамическая картина процессов и список первоочередных улучшений
— DDD: Формализованная доменная модель (агрегаты, сущности, объекты-значения), встроенная в архитектуру приложения

Как они сочетаются?
— Многие команды используют Event Storming на ранней стадии, чтобы собрать «живую картину» предметной области
— В ходе сессий Event Storming формируется общая терминология, выявляются бизнес-объекты и «стыки» (естественные границы в процессе)
— Затем, когда переходим к проектированию приложения, всё это ложится в основу DDD:
— События из Event Storming помогают определить агрегаты и доменные сервисы
— «Стыки» в процессах становятся «ограниченными контекстами»

Преимущества совмещения
— Event Storming позволяет всей команде быстро выровняться по пониманию процессов.
— DDD придаёт этому пониманию структурированную форму и ориентирует на долгосрочный результат.
— События, найденные во время Event Storming, становятся частью единого языка. DDD формализует этот язык и задаёт чёткие рамки для моделей.

По мере прояснения или изменения требований вы можете повторять Event Storming, совершенствуя и уточняя DDD-модель.
Если вы хотите разобраться, как превратить Event Storming в мощный метод анализа и проектирования бизнес-процессов, мы приглашаем вас на наш воршкоп «Event Storming как техника моделирования предметной области и выявления микросервисов».

На воркшопе вы освоите все этапы моделирования, от Big Picture до System Design, и научитесь применять Event Storming как в команде, так и в работе с клиентами.

Регистрация

Каким образом вы интегрируете Event Storming в ваш процесс DDD?

#воркшоп@systems_education #event_storming@systems_education #DDD@systems_education

🎙 Денис Бесков, Основатель школы Systems.Education и Проектировщик бизнес-решений, 26 апреля выступит на конференции по системному и бизнес-анализу Flow с докладов на тему «Что не так с онтологией требований Вигерса и что с этим делать»

Онтология требований Вигерса, хотя и не опирается ни на какие стандарты, остается популярным среди ИТ-аналитиков способом думать о требованиях. Денис использует методики Вигерса более 20 лет, и за это время стали видны нестыковки и проблемы в его модели. Используя языковые методы и подходы системной инженерии, ему удалось придумать, как можно сделать модель Вигерса более точной, сбалансированной и полезной для своей работы. Денис предложит вам эту обновленную онтологию и объяснить, как ее применять.

В этом году конференция Flow проходит бесплатно, регистрация обязательна.

Подробнее тут

#эксперты@systems_education

Воркшоп «Разработка требований к информационной безопасности ИТ-систем»

Воркшоп для системных аналитиков и других ИТ-специалистов, которые хотят выявлять и формировать требования к информационной безопасности

🔹 Когда?
16 — 19 июня

🔹 Что получат участники?
4 занятия по 2 часа

🔹 Чему вы научитесь?
— Строить правильный процесс выявления требований к информационной безопасности
— Формировать требования к информационной безопасности с учетом архитектурных особенностей системы
— Оценивать риски, связанные с безопасностью информации

🔹 Воркшоп будет полезен, если:
— Вы работаете на крупную компанию, коммерческую или государственную
— Ваш продукт или система содержат чувствительные данные, например, относится к сфере финансов или электронной коммерции
— Вы хотите предотвратить сложности и «‎внезапные» доработки безопасности на этапе приемки и эксплуатации
— Вам необходимо точнее оценивать скоуп работ, включая требования, не заявленные явным образом
— Вы не любите заучивать перечни пунктов сертификации или формулировки стандартов
— Ваш процесс разработки включает согласование со службой ИБ

Регистрация

#воркшоп@systems_education #безопасность@systems_education

Опубликовали запись вебинара Натальи Дражник на тему «Как формулировать так, чтобы задачи выполнялись в срок и с нужным результатом»

Тайм-код вебинара:
00:00 Введение
04:12 Что важно учитывать при постановке задач?
09:29 Методики постановки задач
30:29 Как передавать задачу от аналитика в команду (dev+QA)?
34:53 Как контролировать прогресс?
40:20 Что делать, если задачи не выполняются
45:37 Ключевые выводы
50:38 Вопросы и ответы

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

#вебинары@systems_education

Воркшоп «Проектирование сложных API: OpenAPI + AsyncAPI»

🔹 Когда?
17-18 мая (сб/вс)

🔹Что ждать от воркшопа?
— Короткое онлайн-занятие в будни
— 7 часов теории, практики и обратной связи
— Работа в группах до 10 человек
— После окончания поделимся полезными материалами

🔹Воркшоп для
системных аналитиков, которые хотят познакомиться со спецификациями OpenAPI и AsyncAPI, а также научиться проектировать и документировать синхронные и асинхронные API

Зарегистрироваться на воркшоп и узнать подробнее о программе можно тут!

#воркшоп@systems_education

Use Case на собеседовании: что должен знать Junior системный аналитик

На интервью для Junior аналитика нередко задают вопросы, проверяющие понимание Use Case. Вот несколько примеров и как на них можно отвечать:

🔸 1. Что такое Use Case? — Это сценарий использования системы: последовательность шагов взаимодействия акторов с системой для достижения определённой цели пользователя.

🔸 2. Из каких частей состоит Use Case? — В ответе стоит перечислить основные элементы: название, акторы, предусловия, триггер, основной сценарий (шаги взаимодействия), альтернативные сценарии.

🔸 3. Чем Use Case отличается от User Story? — User Story — это краткое описание потребности пользователя, обычно в формате одной фразы на естественном языке (например: «Как покупатель, я хочу сохранить товары в избранное, чтобы купить их позже»). Use Case же — детализированный сценарий поведения системы для реализации этой потребности. Проще говоря, User Story описывает что нужно пользователю, а Use Case — как нужно взаимодействовать с системой, чтобы это достичь.

🔸 4. Как связаны Use Case и тестирование? — Хорошо написанный Use Case фактически описывает ожидаемое поведение системы. Поэтому тестировщики на их основе легко готовят тест-кейсы (конечно, если правильно выделены шаги Use Case).

На воркшопе «Use Case: основы» вы узнаете, почему они важны, из чего состоят, как используются в разработке ПО.
Регистрация

#воркшоп@systems_education #usecase@systems_education

Внедрение С4-модели в проект

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

Почему С4?
С4-модель — это своего рода «универсальный язык», который работает даже с очень сложными проектами. Контекст, контейнеры, компоненты и код — четыре уровня, которые помогают команде видеть одну общую картину и при этом быстро погружаться в детали. По данным опроса ведущих архитекторов систем, грамотное внедрение С4 сокращает время на обсуждение архитектуры на 30%, а число недоразумений по поводу распределения функций между микросервисами или модулями — в среднем на 50%.

Как описать архитектуру ИС с помощью С4-модели?
Набор диаграмм С4 можно рассматривать как структуру из четырёх «слоёв» описания:

1️⃣ Диаграмма Контейнеров (Container Diagram).
Делит систему на логические блоки (веб-приложение, микросервис каталога, оплаты, база данных и т.д.), которые могут рассматриваться и на уровне контейнеров, и на уровне компонентов, в зависимости от требуемого уровня абстракции.
Помогает увидеть, какие технологии и платформы используются для каждого контейнера (например, Java, Node.js, PostgreSQL)
Ответы на вопросы:
«Как разбита система на ключевые части?» и «Какие протоколы или каналы взаимодействия между ними?»

2️⃣ Диаграмма Компонентов (Component Diagram).
Отображает внутреннюю структуру контейнеров, ключевые элементы и их взаимодействие. В микросервисах показывает слои или основные логические блоки (интерфейс, бизнес-логика, доступ к данным), а не привычные модули монолита Удобна для понимания, как реализованы бизнес-функции внутри конкретного сервиса или приложения
Ответы на вопросы:
«Какие основные звенья архитектуры проектируемого решения?» и «Какие технологии используются в нем?»

3️⃣ Диаграмма Кода (Code Diagram).
Наиболее детальный уровень, отражающий важные классы, методы, структуры данных или АРІ внутри отдельных компонентов
Нужна для ситуаций, когда команде действительно нужно детально показать решение на уровне исходного кода, но часто опциональна
Ответы на вопросы:
«Как выглядит структура ключевых классов?» и «Какие паттерны или библиотеки применяются?»

Использование всей цепочки диаграмм С4 обеспечивает целостное понимание: от общего контура взаимодействий до глубины реализации.

Хотите углубить свои знания в микросервисной архитектуре?
Приглашаем вас на воркшоп «Паттерны проектирования микросервисной архитектуры и нотация С4». За короткое время вы научитесь использовать четыре уровня диаграмм, связывать их с бизнес-требованиями и показывать заказчикам понятную архитектурную схему.

Регистрация

#воркшоп@systems_education
#C4@systems_education
#C4Notation@systems_education

🗓 25 апреля, 18:30 мск, Пятница
📍Офлайн | 💻 Онлайн

🔧 Инструменты для тех, кто проектирует системы

Это будет пятница. Доклады по 10 минут, на которых —
каждый спикер отдаст в руки инструмент: фреймворк, методику или конкретный шаблон, которые можно применить уже в понедельник.

Поговорим о системном мышлении через архитектурные ката, превращении документации в то, чем реально хочется пользоваться, генеративном ИИ как новом мультитуле аналитика, и JBTD как подходе, который помогает фокусироваться на задачах, а не хотелках.

🎤 В конце ребята из ХАП проведут PowerPoint-караоке,
— команды, случайные слайды и импровизация на максималках.
И конечно же, "база": нетворкинг, закуски

Про инструменты расскажут:
🪛 Глеб Гончаров — придёт с инструментом архитектурных ката
🧲 Денис Бесков — принесёт ИИ-мультитул аналитика
🔩 Дмитрий Безгулый — JTBD-фреймворк для аналитиков и проектировщиков
🛠 Максим Чернухин — раскроет принцип проектирования против легаси
🧰 Дарья Мороз — придёт с UX-набором для документации

Организаторы — Ви.Tech, команда инженеров из ВсеИнструменты.ру
Спецгости и движ — Холиварные аналитические посиделки

Обязательно приходите — тут регистрация.

С каких UML диаграмм начать, чтобы не потеряться?

UML часто воспринимается как нечто сложное и «только для архитекторов». Но на самом деле — это один из самых понятных и логичных способов визуализировать требования, логику и архитектуру, если начать с правильных диаграмм.

Принцип «от простого к сложному»

Чтобы не утонуть в элементах нотации и не отпугнуть себя UML'ом навсегда, советуем начать с трёх диаграмм, которые:
— используются чаще всего в проектах
— легко читаются даже новичками
— применимы к любой системе: от интернет-магазина до облачного сервиса

🔸 1. Диаграмма прецедентов (Use Case Diagram)

Для чего: описывает, кто взаимодействует с системой и какие функции доступны.

Почему с неё начать:
— Это почти «карта» пользовательских сценариев
— Простая и наглядная: «пользователь → действие»
— Хорошо заходит на встречах с заказчиком

Пример: показать, что «Пользователь» может «оформить заказ», «посмотреть профиль» и «оплатить покупку».

🔸 2. Диаграмма классов (Class Diagram)

Для чего: описывает структуру системы: сущности, их свойства и связи.

Почему с неё начать:
— Дает понимание «из чего состоит система»
— Идеальна для описания предметной области
— Помогает разработчику понять, что реализовывать

Пример: у вас есть классы «Пользователь», «Заказ» и «Товар», и вы показываете связи между ними: один пользователь — много заказов, заказ содержит товары.

🔸 3. Диаграмма последовательности (Sequence Diagram)

Для чего: показывает, как объекты взаимодействуют между собой во времени.

Почему с неё начать:
— Прекрасно объясняет бизнес-логику
— Помогает найти узкие места и пропущенные шаги
— Упрощает общение между аналитиком и разработкой

Пример: отобразить, как пользователь оформляет заказ — от клика до записи в базу данных.

Если вы хотите постепенно погрузиться в тему UML, приглашаем вас на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования», где вы на практике познакомитесь с одной из самых популярных и часто используемых диаграмм.
Подробнее о воркшопе

А для тех, кто хочет все и сразу, у нас есть курс «Проектирование информационных систем с помощью UML», где вы так же на практике изучите все самые необходимые диаграммы.
Подробнее о курсе

#воркшоп@systems_education #курс@systems_education #uml@systems_education

Мы спросили выпускников «Systems Analyst Bootcamp» о самых неожиданных и каверзных вопросах, которые им задавали на собеседованиях на позицию СА. Самые интересные вынесли на карточки. 📤

На собеседованиях оценивают не только знания, но и гибкость, здравый смысл и умение быстро реагировать.

Если вы уже давно рассматриваете профессию СА, хотите быстрый карьерный старт или уже не первый месяц боретесь с «синдромом самозванца», на «Systems Analyst Bootcamp» за 3 месяца вы получите профессию системного аналитика, которая соответствует актуальным требованиям вакансий на рынке.

Подробнее

#буткемп@systems_education

24 апреля (чт) в 19:00 (мск) пройдёт вебинар на тему «От идеи до MVP: как создается архитектура ИТ-решения шаг за шагом» с экспертом школы Systems.Education Мирой Карлаш

На практике ведущая покажет, как спроектировать и собрать архитектуру ИТ-продукта от use-case диаграммы до MVP. Мы шаг за шагом разберём компоненты, архитектурные решения, базу данных, интеграции (почта, Telegram, вебхуки), события и покажем, как всё это работает как единое целое.

▫️План вебинара
1. Постановка задачи и требований
2. Моделирование данных
3. Сценарии взаимодействия
4. Интернет-технологии и форматы передачи
5. REST API: реализация и тестирование
6. Асинхронное взаимодействие
7. Современные подходы к интеграции
8. Финальный обзор архитектуры проекта

▫️Вебинар будет полезен:
— Системным аналитикам, которые хотят научиться проектировать архитектуру с нуля и аргументировать решения
— Разработчикам и архитекторам, которые стремятся структурировать подход к созданию MVP
— ИТ-менеджерам и CTO, которым важно понимать, как выстраивается современная архитектура без лишней теории

▫️Ведущая вебинара — Мира Карлаш, Эксперт Systems.Education, Инженер по требованиям, Эксперт в области применения Data Science в медицине с фокусом на диагностику и анализ данных для сложных заболеваний

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

Регистрация

❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.

#вебинар@systems_education

Воркшоп «Проектирование интеграции с REST API»

🔹Когда?
26-27 Апреля

🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки

🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона

Регистрация

#воркшоп #интеграция #RESTAPI

Воркшоп «Паттерны проектирования микросервисной архитектуры и нотация С4»

🔹 Когда?
31 Мая — 1 Июня (сб/вс)

🔹 Воркшоп по проектированию архитектуры информационных систем для системных аналитиков, которые хотят познакомиться с популярными паттернами проектирования микросервисной архитектуры и научиться их визуализировать в диаграммах нотации С4

🔹 Цель обучения:
— Познакомиться с популярными паттернами проектирования микросервисной архитектуры, углубить свои знания.
— Научиться проектировать архитектуру информационных систем и визуализировать их в диаграммах нотации С4.

Регистрация

#воркшоп@systems_education #C4Notation@systems_education #C4@systems_education

Опубликовали перевод 6 главы книги «Основы инженерии данных» на тему «Хранение»

В этой главе рассказывается о том, как устроено хранение данных и почему оно критически важно в жизненном цикле инженерии данных. Авторы подробно разбирают основные компоненты (жёсткие диски, SSD, оперативная память), принцип работы систем хранения (файловых, блочных, объектных), а также ключевые концепции вроде сериализации, сжатия, кэширования и различных уровней доступа к данным (горячие, тёплые, холодные). Особое внимание уделяется тому, как правильно выбирать и комбинировать технологии хранения, какие есть компромиссы между скоростью, надёжностью и затратами, и как поддерживать всю инфраструктуру в крупных проектах — от локальных файловых систем до облачных хранилищ и «озёр данных».

Содержание главы:
1. Основные компоненты для хранения данных
2. Системы хранения данных
3. Абстракции хранения в инженерии данных
4. Идеи и тенденции в области хранения данных
5. С кем вы будете работать
6. Фоновые процессы

Почитать можно тут

#статья@systems_education #базы_данных@systems_education

UML + Domain-Driven Design

Всем знакомы эти 2 лагеря:
1. Те, кто рисует UML-диаграммы
2. Те, кто говорит, что UML — это скучно, и лучше работать по DDD

А что если мы скажем, что эти подходы отлично работают вместе — и в связке дают максимальный эффект?

DDD в жизни — много смысла, мало визуализации

Domain-Driven Design учит нас мыслить в терминах домена:
— сущности, которые важны бизнесу
— действия, которые с ними происходят
— границы, которые нельзя нарушать

Но в жизни часто выходит так:
— бизнес говорит «товар», а разработка — «product»
— один микросервис называет это классом, другой — JSON'ом
— архитектор кидает диаграмму, где ничего не понятно без Rosetta Stone

И как же всем найти общий язык — использовать UML

Давайте пройдёмся по нескольким примерам с UML диаграммами

🖥 Диаграмма классов (Class Diagram) = сердце DDD
— Покажет Entities, Value Objects и Aggregates на одной схеме
— Сформирует единый язык между разработкой и бизнесом
— Чётко отразит, какие поля хранятся, какие методы допустимы, а какие — нет

🖥 Диаграмма прецедентов (Use Case) = кто и зачем взаимодействует с системой
— Простая картинка для Product Owner'а
— Хороший способ согласовать бизнес-функции до того, как команда «улетит в реализацию»

🖥 Диаграмма последовательности (Sequence) = как работает сервис
— Покажи сценарий, как сервис обрабатывает команду Создать заказ и какие доменные события порождает
— Это особенно полезно при работе с event-driven архитектурой

В нашей школе у тебя есть возможность познакомиться как с UML диаграммами, так и Event Storming, одной из техник DDD.

Курс по UML
Воркшоп по Event Storming

#воркшоп@systems_education #курс@systems_education #uml@systems_education

— Как они с этим справились?
— Интересно, где они сейчас?
— Как это было?
— А я смогу так же?

Каждый из нас задавался этими вопросами, когда читал о «Systems Analyst Bootcamp» и его выпускниках!

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

🤔Это правда звучит, как серьёзный вызов!

А что если....
Мы спросим, как это было, из первых уст?

Мы пригласили выпускника прошлогоднего мартовского потока Александра Цаплина, чтобы он ответил на все интересующие вас вопросы.

Немного об Александре:
— До буткемпа работал в РФ в крупной нефтяной компании бизнес-аналитиком
— Сейчас работает в крупнейшей нефтяной компании в другом государстве руководителем IT проектов

После обучения на буткемпе получил оффер от международного проекта, в чем сильно поспособствовали знания и умения, полученные на курсе. Александр перешёл на такую же должность, но на более высокую зарплату. Всего через 3 месяца окончания обучения Александр на новом месте работы приступил к проектированию информационной системы для HR с нуля и выполнил эту задачу за осень 2024. С января 2025 года ИС запущена в разработку. За январь-февраль выполнил проектирование ИС для технологически сложного домена. ИС с 1 апреля запущена в разработку. Александр был назначен руководителем обоих проектов.

⚡️ Только на этих выходных Александр в комментариях к этому посту ответит на все интересующие вас вопросы. Они могут быть связаны как с самим буткемпом — сложность прохождения, атмосфера в команде или отзыв о преподавателе, так и с карьерой Александра — его актуальные задачи, все ли знания с курса пригодились.

Познакомиться поближе с «Systems Analyst Bootcamp» можно по ссылке

НЕТВОРКИНГУ БЫТЬ!
Ждём ваши вопросы в комментариях ⬇️

17 апреля (чт) в 19:00 (мск) пройдёт вебинар на тему «Постановка задач: как формулировать так, чтобы задачи выполнялись в срок и с нужным результатом» с приглашённым экспертом Натальей Дражник

Вебинар посвящён методам постановки задач и мониторинга прогресса.

▫️Мы разберём:
— Что такое SMART, CSD, RACI и как выбрать подходящий метод
— Как переформулировать задачу так, чтобы её действительно сделали и в срок
— Как контролировать выполнение и отслеживать прогресс (канбан, чек-листы, дашборды, PDCA)
— Реальные примеры из жизни продуктовых и технических команд

▫️Вебинар будет полезен:
— Продуктовым менеджерам, которые формируют задачи для разработки
— Системным и бизнес-аналитикам, которым важно, чтобы требования точно превращались в работающий результат
— Руководителям команд, стремящимся к прозрачности, эффективности и управляемым срокам
— Разработчикам и техлидам, которые хотят лучше коммуницировать с продуктовыми и аналитическими ролями
— Всем, кто работает с задачами и хочет, чтобы они выполнялись, а не терялись по пути

▫️Ведущая вебинара — Наталья Дражник, Product Owner с опытом работы в FinTech, HRTech и MarTech, а также в разработке бэкофис-систем и аналитических платформ.

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

Регистрация

❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.

#вебинар@systems_education

🔔 LAST CALL 🔔

Уже завтра стартует Третья конференция «Systems Design Online»

Для конференции мы подготовили 3 тематические секции — Архитектура, Искусственный интеллект, ML и Data Engineering.

— В секции, посвящённой архитектуре, мы сосредоточимся на том, как проектировать гибкие, масштабируемые и надёжные системы, учитывая широкий спектр технологических и бизнес-требований.
— Секция «Искусственный интеллект и Машинное обучение» освещает современные методы и практики, позволяющие использовать потенциал данных и интеллектуальных систем в бизнесе.
— В фокусе секции «Data Engineering» — комплексные аспекты работы с данными: от сбора и хранения до обработки, анализа и предоставления в удобном виде конечным пользователям и системам.

Всего вас будут ждать 24 доклада. Расписание доступно на сайте!

⏰Встречаемся в 9:00 МСК

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

🛰 Владимир Иванов, Software Architect с более чем 15-ти летним опытом, выступит на третьей конференции Systems Design Online с докладом на тему «Не переплачивай за инфраструктуру!»

О докладе:
Доклад посвящен концепции Frugal Software Architecture (Бережливой архитектуре), которая предполагает осознанное управление ресурсами и затратами при разработке программных решений. Основная цель такого подхода — достижение максимальной эффективности с минимальными вложениями, что особенно актуально в условиях текущей экономической нестабильности и ограниченных ресурсов.

Слушатели познакомятся с основными принципами бережливой архитектуры и узнают о возможных преимуществах и проблемах её использования.

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

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

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

Опубликовали запись вебинара Дениса Прилепского на тему «AI-управляемые архитектуры данных в корпоративных системах»

Тайм-код вебинара:
00:00 Введение
02:08 Необходимость принятия решений в реальном времени
04:38 Применение AI-архитектур в различных отраслях
09:20 Основы AI-driven архитектур
40:40 Практические рекомендации по построению архитектур ИИ в реальном времени
43:23 Критические уроки по построению архитектур ИИ в реальном времени
47:30 Вопросы зрителей

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

На конференции Systems Design Online 12 апреля (сб) Денис выступит с докладом, в котором расскажет о реальном кейсе применения знаний с прошедшего вебинара. Присоединяйтесь!

Подробнее о докладах и воркшопах конференции здесь
Канал конференции @systems_design_online

#вебинары@systems_education

Визуальные фишки Sequence Diagram, которые сделают твою диаграмму не просто красивой, но и понятной

➡️Сначала стоит понять уровень детализации
— Заказчику — минимум технической информации Показываем роли (актеров) и ключевые шаги: заказ → оплата → доставка. Без методов и асинхронных вызовов.
— Аналитику — логика сценария, включая граничные случаи. Важно отразить условия (alt, opt), таймауты, возвраты, сообщения об ошибках. Sequence Diagram — это повод для уточнений, а не финальный артефакт.
— Разработчику — максимум конкретики. Им нужны имена методов, структуры сообщений, типы взаимодействий (синхрон / асинхрон), а также информация о контексте (транзакции, авторизация и т.д.).

➡️Использование цветовых паттернов
— Серый фон для системных компонентов (например, БД или Kafka) — визуально отделяем от активных участников
— Зелёный — для пользовательских действий
— Оранжевый — внешние системы
— Красный или ⚠️ — сообщения об ошибках или критические точки (например, возможный таймаут)

➡️Структурные паттерны
— Сгруппируй участников по слоям (Frontend → Backend → External)
— Используй заголовки (ref) для повторяющихся сценариев (например, авторизация)
— Если блок логики сложный — выдели его alt или loop с пояснением
— Добавляй комментарии — сноски рядом с сообщениями, объясняющие, зачем это делается

Если ты еще не знаком с данной UML-диаграммой, приглашаем на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования», на котором ты под руководством эксперта научишься строить Sequence диаграммы, читать их и использовать для проектирования поведения систем.

Регистрация

#воркшоп@systems_education #uml@systems_education #sequence@systems_education

🛰 Виктор Рудь, Эксперт в области корпоративной архитектуры с 10-летним опытом работы для предприятий федерального масштаба, выступит на третьей конференции Systems Design Online с докладом на тему «Проектирование корпоративной архитектуры»

План доклада:

1. О сущности корпоративной архитектуры
— Архитектура — это модель организованности предприятия
— Компоненты в архитектуре
— Связи/отношения компонентов архитектуры
— Что контролирует корпоративный архитектор

2. Каталогизация компонентов архитектуры
— Типы компонентов корп. архитектуры
— О нормализации компонентов
— Эволюция компонентов по Захману
— Способы выделения поведенческих элементов
— Способы выделения сущностей (объектов данных)
— Атомарные операции над данными

3. Роль инструмента в описании архитектуры
— Роль метамодели
— Классы решаемых задач

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

Мы открываем набор на новый онлайн-курс «Проектирование микросервисов», разработанный специально для опытных системных аналитиков, желающих углубить свои знания и умения в области современных архитектурных решений.

О курсе:

* Формат: онлайн-обучение в группе до 12 человек.​

* Продолжительность: 6 занятий по 4 часа в течение 2–3 недель.​

* Стоимость участия в пилоте: 24 000 руб. для частных лиц; 36 000 руб. для участников от компаний.​

Программа курса включает:

1. Выявление первичной структуры и поведения ИС:

* Определение ограниченных контекстов и пользователей с помощью Event Storming.​

* Документирование контекста в С4 и вариантов использования в use case.​

2. Выделение микросервисов:

* Декомпозиция системы на микросервисы.​

* Выбор технологий хранения и обработки данных.​

* Определение контейнеров и компонентов на С4.​

3. Проектирование интеграций микросервисов:

* Определение подходов и технологий организации взаимодействия между сервисами.​

* Документирование в UML-sequence.​

4. Обеспечение качества микросервисов:

* Способы обеспечения безопасности, надёжности, масштабируемости и развёртывания системы с микросервисной архитектурой с использованием соответствующих паттернов.​

* Добавление дополнительных элементов на диаграммы С4.​

5. Проектирование контрактов:

* Определение контрактов данных для RESTful-сервисов (разработка спецификации OpenAPI).​

6. Проектирование асинхронной интеграции через брокеры сообщений:

* Проектирование потокового конвейера.​

* Разработка спецификаций AsyncAPI для Apache Kafka и RabbitMQ.​

Преимущества курса:

* Практическая направленность: каждый модуль сопровождается документированием архитектурных решений в легковесном ADR.​

* Опытные преподаватели: эксперты с более чем 10-летним опытом в ИТ, разработке и проектировании архитектуры.​

* Интерактивное обучение: возможность работы в малых группах, выполнение заданий в команде из 3–4 аналитиков.​

Как только будет собрано достаточное количество заявок, мы запланируем даты проведения пилота и согласуем их с теми, кто записался.

Ловушки системных требований: 5 показательных примеров, когда небольшая деталь приводила к серьёзным проблемам

Как одна пропущенная строка в ТЗ может стоить миллионы? Почему кажущееся «всем понятное» требование вдруг ломает всю архитектуру?
Мы собрали пять историй, где малейшая неточность в требованиях приводила к коллапсу — читайте в карточках 📤

Как избежать подобных ловушек?

1. Работайте с требованиями на раннем этапе
Пропишите функциональные и нефункциональные требования (скорость, масштабируемость, форматы отчётности, локализацию). Опирайтесь на стандарты ISO 25010, INCOSE, PMI, чтобы не забыть «тонкие» аспекты.

2. Внедряйте контекстные и DFD-диаграммы
Показывайте, откуда и куда идут данные, какие сценарии «edge case» могут всплыть. Любой offline-режим, смена локали или неожиданный скачок трафика должны стать частью модели.

3. Связывайте стейкхолдеров
Чаще всего юристы, менеджеры, снабженцы и прочие службы имеют критически важные требования, но «забывают» участвовать. Научитесь вовлекать их ещё до начала разработки, используя методики системного анализа.

4. Закрепляйте метрики
Вместо «быстрый отклик» — «среднее время ответа до 1 секунды при 500 параллельных запросах». Вместо «надёжная система» — «доступность 99.5% в год». Такие метрики можно тестировать и мониторить.

💬 А в какие ловушки попадала ваша команда? Делитесь в комментариях

На курсе «Системный анализ + ИИ. Разработка требований и функциональное проектирование систем» вы научитесь выявлять и формулировать требования к программной системе и создадите законченный документ Требований к ПО (SRS)
Подробнее о курсе

#курс@systems_education #системный_анализ@systems_education

Почему компании продолжают активно пользоваться методологией Data Vault в своей работе?

Согласно исследованию 2023 года от BARC GmbH, Eckerson Group, в 2010-е Data Vault использовало лишь несколько процентов компаний, а к 2023 году эта доля выросла до 28%. Причём 91% тех, кто уже внедрил Data Vault, планируют расширять его применение. Этот рост объясняется тем, что Data Vault хорошо подходит для быстрых изменений данных и позволяет хранить их полную историю, что особенно востребовано в эпоху цифровой трансформации.

Давайте посмотрим, как именно Data Vault ускоряет разработку и упрощает сопровождение сложных систем!

1️⃣ Минимальное число сущностей — максимум эффективности
Data Vault использует всего три основных типа объектов: «хабы», «ссылки» и «спутники». «Хабы» представляют собой ключевые бизнес-сущности (например, «Клиент»). «Ссылки» указывают, как эти сущности связаны друг с другом (например, «Клиент» ↔ «Заказ»). «Спутники» содержат дополнительные характеристики и историю изменений (например, адрес, контакты, сумму заказа). Благодаря такой простой структуре разработчики и аналитики быстро находят нужные данные.

2️⃣ Гибкая и быстрая ETL-разработка
ETL (Extract, Transform, Load) — это набор операций для извлечения данных из разных источников, их преобразования и последующей загрузки в хранилище. При использовании методологии Data Vault новые или обновлённые данные из исходных источников обрабатываются параллельно по нескольким потокам — «хабы», «ссылки» и «спутники» распределяются на отдельные конвейеры — и быстрее загружаются в хранилище. Это ускоряет обновления, что важно при работе с информацией в режиме реального времени или при минимальной задержке.

3️⃣ Экономия места и ресурсов
В хранилище, построенном по принципам Data Vault, сохраняются только новые или изменённые данные — «дельты» — в «спутниках». Например, если у «Клиента» изменился адрес, то в «спутник» добавляется лишь новая версия адреса, а не копируется вся запись. В условиях Big Data, когда данные разных форматов поступают с высокой скоростью, это особенно важно, ведь каждый лишний столбец приводит к дополнительным затратам на хранение. Если объём в одной таблице-«спутнике» растёт слишком быстро, её легко разделить на несколько более узких «спутников» по группам атрибутов. Такой подход сводит к минимуму риск замедления обработки таблицы и повышения расходов на хранение.

4️⃣ Масштабирование без сложностей
Когда в компании появляются новые KPI, бизнес-процессы, форматы отчётности или источники данных, методология Data Vault даёт возможность точечно расширять существующую структуру данных новыми «хабами», «ссылками» и «спутниками» без полной перестройки. При этом уже построенная модель почти не меняется, что снижает риски и затраты внесения изменений.

5️⃣ Работа по Agile-принципам
DV хорошо сочетается с Agile и Scrum, которые предполагают короткие итерации и быструю адаптацию к изменениям. Подход Data Vault позволяет вносить изменения постепенно, не затрагивая уже работающие части системы. Если нужно подключить новые источники данных — например, дополнительную CRM-систему или внешний API — достаточно локально добавить соответствующие «хабы», «ссылки» или «спутники», это можно сделать, не нарушая работу существующего хранилища.

6️⃣ Прозрачность изменений
Data Vault фиксирует и хранит информацию обо всех изменениях в составе и структуре данных, например, при добавлении новых полей, перестройке связей или удалении устаревших элементов. Такая детальная прослеживаемость версий обеспечивает высокий уровень аудируемости, который важен не только для внутреннего контроля качества и порядка работы с данными, но и при проверках регуляторов, требующих подтверждения корректности и достоверности внесённых сведений.

Если вы хотите на практике познакомиться со всеми преимуществами DV, приглашаем вас присоединиться к нашему воркшопу на тему «Проектирование DWH по методологии Data Vault», где мы поэтапно разберем принципы Data Vault и поделимся примерами проектирования модели Raw и TransFormed слоя Data Vault.

Регистрация

#воркшоп@systems_education

База данных — основа любой информационной системы

Что такое информационная система?

Информационная система (ИС) — это совокупность взаимосвязанных компонентов (людей, процессов, аппаратного и программного обеспечения), предназначенных для сбора, хранения, обработки и передачи данных. Основная задача ИС — обеспечить доступ к нужной информации в нужный момент и упростить принятие решений.

Что такое база данных и зачем она нужна в ИС?

База данных (БД) — это структурированное хранилище, где аккумулируется вся необходимая для работы системы информация. Правильно настроенная БД гарантирует:
— Надёжное хранение больших объёмов данных
— Быстрый поиск и обновление информации
— Поддержание целостности и согласованности данных

Организации могут работать с различными объёмами и типами данных (текстовые, мультимедийные, метрические). Именно поэтому существует множество видов систем управления базами данных (СУБД): реляционные, документно-ориентированные, графовые и т.д. При этом на одном и том же наборе данных разные СУБД могут решать принципиально разные задачи, поэтому крайне важно выбрать правильную СУБД, способную обеспечить требуемые показатели производительности системы.

Чтобы доступ к информации был быстрым, её необходимо структурировать в БД по определённым правилам. В этом и заключается основной принцип проектирования баз данных, который позволяет избежать дублирования и потери данных, а также упростить их анализ и дальнейшее развитие системы.

⚙️ С ЧЕГО НАЧАТЬ ПРОЕКТИРОВАНИЕ БД?

Правильный старт — моделирование предметной области, в которой функционирует ИС. Это позволит еще на ранних этапах проектирования понять взаимосвязь объектов и событий домена. Этот процесс включает:
— Определение основных объектов (сущностей) предметной области;
— Определение их характеристик (атрибутов), необходимых для работы системы.

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

Изучите, как подобрать оптимальную СУБД для работы с большими данными, ознакомившись со статьёй из нашей базы знаний по ссылке

Для повышения квалификации системных аналитиков и совершенствования умений проектирования баз данных, мы предлагаем принять участие в воркшопе «Моделирование предметной области и Проектирование базы данных»
Регистрация

#воркшоп@systems_education #базы_данных@systems_education #моделирование@systems_education

Остаются считанные места на мастер-класс «Архитектурные решения и AI», который пройдет во второй день конференции «Systems Design Online»

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

🔹Мастер-класс будет полезен:
— Старшим инженерам
— Тимлидам
— Архитекторам
— Специалистам, которые принимают архитектурные решения

🔹Для успешного прохождения мастер-класс необходимо:
— Заранее установить софт: Llama (локальный столяр для моделей)

🔹Что узнают участники мастер-класса:
— Разные способы применения больших языковых моделей
— Как анализировать текущие архитектурные решения
— Как анализировать архитектурные схемы с помощью LLM
— Как создавать документацию к архитектурным решениям

🗓 Пройдёт мастер-класс 13 апреля (вс), 11:00-13:00 МСК
👥 Ведущий — Владимир Иванов, Старший менеджер по разработке в Bolt, Ведущий тг-канала Architecture Weekly @architectureweekly

Регистрация на мастер-класс
Подробнее о докладах и других воркшопах конференции здесь
Канал конференции @systems_design_online

#выступления@systems_education

Как найти узкие места до того, как они появятся в проде

Если у вас есть ощущение, что диаграммы последовательности — это просто иллюстрация цепочки вызовов, то держитесь: вы их недооцениваете!

🖥 Sequence Diagram — это больше, чем схема взаимодействия. Это диаграмма профилактики системных проблем.

Где обычно прячутся узкие места?
— Избыточные вызовы
— Слишком долгая цепочка
— Асинхронные ловушки. Выглядит как «вызвал и забыл», а по факту — потерянные события
— Дублирование логики. Когда два сервиса делают почти одно и то же — и оба об этом не знают
— Неразделённые ответственности

Sequence Diagram в таких случаях помогает:
— Визуализацией сценариев end-to-end
— Считает шаги. Сколько взаимодействий нужно, чтобы выполнить одно действие?
— Оценивает зависимости. Что будет, если один сервис «упадёт»? Диаграмма покажет уязвимые звенья.
— Ищет циклы. Loop-блоки на диаграмме часто указывают на неэффективные алгоритмы.
— Видит, где нужна буферизация. Особенно в системах с высоким трафиком — очередь сообщений должна быть видна на диаграмме.

Если ты еще не знаком с данной UML-диаграммой, приглашаем на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования», на котором ты под руководством эксперта научишься строить Sequence диаграммы, читать их и использовать для проектирования поведения систем.

Регистрация

#воркшоп@systems_education #uml@systems_education #sequence@systems_education

Алина Богачёва, Архитектор бизнес-решений в области финансов, CEO и CFO Systems.Education выступит на IT Global Meetup #17 с докладом на тему «Алгоритм проектирования бизнес-алгоритмов»

Алина расскажет, как с помощью четырёхшагового алгоритма проектировать бизнес-процессы так, чтобы не пропустить негативные или альтернативные ветви. Этот подход помогает формализовать логику и избежать дорогих ошибок, возникающих при неполном учёте исключительных случаев.

Подробности и регистрация
❗️Участие бесплатное❗️

🗓 13 апреля 2025

📍 Азимут отель Санкт-Петербург Лермонтовский пр. 43/1

🛰 Михаил Першин, Lead Backend Engineer в HaHa Inc и Архитектор криптоприложений, выступит на третьей конференции Systems Design Online с докладом на тему «1000 -> 500к: успех или провал?»

О докладе:
Как подготовиться к ожидаемому взрывному росту:
— Проактивные меры — куда смотреть, а куда нет
— Технологические решения — как поднять то, что уже лежит
— Процессный подход — как и что организовывать, а что можно пропустить
— Ментальный настрой — как совладать с паникой в команде и коммьюнити

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

13 апреля (вс) в рамках конференции «Systems Design Online» пройдёт воркшоп «Принятие и документирование архитектурных решений»

🔹Воркшоп будет полезен:
— Системным аналитикам уровня Middle- (и выше)
— Специалистам, занимающиеся проектированием и интеграцией сервисов
— Архитекторам решений

🔹На воркшопе вы научитесь:
— Осознанно подходить к проектированию решений
— Фиксировать архитектурные решения, используя ADR (Architectural Decision Records)
— Работать с несколькими вариантами архитектурных решений, анализировать их плюсы и минусы
— Повысить уровень взаимодействия в команде при обсуждении архитектуры

🔹Программа воркшопа:
1. Введение 
2. Первая итерация
— Участники работают в группах, решают задачу
— Оформляют архитектурные решения
3. Разбор первой итерации
— Группы меняются результатами
— Анализируют чужие решения, вносят правки
4. Вторая итерация
— Уточнение и адаптация решений
— Документирование принятых решений
5. Финальный разбор
— Обсуждение типичных проблем
— Выводы, рекомендации

🔹Для успешного прохождения воркшопа необходимо:
— Иметь базовое понимание проектирования информационных систем
— Опыт участия в принятии решений по архитектуре ПО
— Интерес к процессам интеграции сервисов

🗓 Пройдёт воркшоп 13 апреля (вс), 16:00-18:00 МСК
👥 Ведущий — Максим Шаломович, Архитектор Решений в крупных корпоративных и государственных проектных инициативах

Регистрация на воркшоп
Подробнее о докладах и других воркшопах конференции здесь
Канал конференции @systems_design_online

#выступления@systems_education

Опубликовали перевод 5 главы книги «Основы инженерии данных» на тему «Генерация данных в исходных системах»

В этой главе рассказывается о первом этапе жизненного цикла инженерии данных — генерации данных в исходных системах. Авторы описывают, как и где возникают данные (например, в базах данных приложений, через API, логи, потоковые платформы), а также дают обзор ключевых понятий, которые важно учитывать инженеру данных (OLTP, OLAP, ACID, CDC и др.). Подчёркивается важность понимания природы и особенностей исходных систем, взаимодействия с командами, которые их поддерживают, и учёта фоновых процессов (безопасность, управление данными, DevOps, архитектура). Главная идея — научиться правильно «забирать» данные из источников, не нарушая работу систем, и понимать, как их особенности влияют на качество и дальнейшую обработку этих данных.

Содержание главы:
1. Источники данных: Как создаются данные?
2. Исходные системы: Основные идеи
3. Практические сведения об исходных системах
4. С кем вы будете работать
5. Фоновые процессы и их влияние на исходные системы

Почитать можно тут

#статья@systems_education

🎥 Выложили запись доклада Евгения Лыкова с конференции Systems Design 24 на тему «Проектирование медицинского ассистивного ПО в условиях высокой неопределённости»

Ex-CTO и ведущий программный инженер Visionis Евгений Лыков представил доклад, поделившись опытом разработки стартапа EyeDoo, который позволяет управлять компьютером с помощью взгляда. В своём выступлении он подробно рассмотрел ключевые аспекты, включая трудности проектирования, поиск точек опоры, выбор платформы и языка, а также этические вопросы, подчеркнув важность гибкости и адаптации в условиях неопределённости.

Тайм-код доклада:
00:00 О спикере
01:35 Трудности с проектированием
03:44 Описание стартапа EyeDoo - управление компьютером при помощь взгляда
06:37 Неопределённости стартапа
09:50 Поиск точек опоры
12:01 Платформа
15:08 Язык
17:47 Система
19:38 Версионность
21:27 Продукт
24:45 Вспомогательные технологии
26:44 Этическая составляющая
28:01 Выводы

Посмотреть можно на нашем You-Tube канале

🚀 12-13 апреля состоится третья конференция Systems Design Online

Конференция Systems Design Online будет интересна:
— разработчикам и аналитикам
— архитекторам и руководителям ИТ-проектов
— всем, кто стремится повышать эффективность бизнес-процессов при помощи современных технологических решений

Подробнее о конференции здесь
Канал конференции @systems_design_online

#выступления@systems_education

🛰 Виталий Щур, Lead/Senior QA, выступит на третьей конференции Systems Design Online с докладом на тему «Революция в технической документации с помощью ИИ»

О докладе:
Успешные проекты требуют четкой, актуальной и хорошо структурированной документации. Однако её создание и поддержка — сложный и трудозатратный процесс.
Мы рассмотрим, как искусственный интеллект помогает:
— Генерировать эпики, юзер-стори и тест-кейсы на основе требований
— Поддерживать документацию в актуальном состоянии
— Обеспечивать согласованность терминологии и удобочитаемость
— Оптимизировать тестирование с помощью AI-генерируемых сценариев
— Ускорять написание кода разработчиками, улучшать комментарии, документировать существующий код и API

Мы поговорим о ключевых AI-инструментах, такие как ChatGPT, Atlassian Intelligence и GitHub Copilot, которые делают техническую документацию более точной, быстрой в создании и лёгкой в сопровождении. ИИ — это не замена человеку, а мощное средство автоматизации, позволяющее командам сосредоточиться на разработке, а не на рутинных задачах.

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

Дайджест курсов и воркшопов школы на апрель 🌺

Сохраняйте пост, чтобы потом не потерять!

🔹Курсы:

Системный анализ. Разработка требований и функциональное проектирование систем (19 Апреля-11 Мая)

Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения
Регистрация

🔹Воркшопы:

1️⃣ BPMN для людей: основы самой популярной нотации для описания бизнес-процессов (с 8 апреля)

Воркшоп для ИТ-специалистов, которые хотят научиться описывать логику выполнения бизнес-процессов с помощью формальной нотации — BPMN
Регистрация

2️⃣ Проектирование DWH по методологии Data Vault (с 16 апреля)

Data Vault, методология проектирования DWH, проще якорной модели (Anchor Modeling), но также обладает высокой гибкостью и лучше подается дополнению и расширению по сравнению с классическими звёздными схемами по Кимбалу и Инмону
Регистрация

3️⃣ Моделирование предметной области и Проектирование базы данных (21 апреля)

Воркшоп для системных аналитиков и не-разработчиков уровня джун-мидл, которые хотят спроектировать логическую модель базы данных и изучить основы нормализации баз данных. Особенно актуально для тех, кто ещё не знаком с базами данных
Регистрация

4️⃣ UML-диаграммы последовательности для аналитика: ликбез и примеры использования (23 апреля)

На воркшопе за 3 часа вы построите sequence диаграммы и убедитесь что:
— Cтроить sequence диаграммы несложно
— UML диаграммы удобно читать и легко понимать
— UML — отличный инструмент проектирования поведения систем
Регистрация

5️⃣ Проектирование интеграции с REST API (с 26 апреля)

Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки
Регистрация

#дайджест@systems_education

📣 Расписание готово!

На сайте конференции доступно расписание всех трёх потоков докладов, которые пройдут в первый день (12.04, сб)

Начнём мы в 9:00 МСК, закончим в 18:00 МСК. В каждом параллельном потоке вас будут ждать по 8 докладчиков. Вы уже сейчас можете планировать первый день конференции, отметив наиболее интересные для вас выступления.

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

🚀 Встречаемся уже через неделю!

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

Как избежать интеграционного ада при проектировании MVP?

Представьте: вы разработали MVP, пользователи довольны, метрики растут. Но вот приходит момент, когда нужно интегрировать платежную систему, подключить CRM или запустить мобильное приложение… И тут оказывается, что API в вашем MVP нет, либо оно хаотично, либо привязано к внутренней логике так, что любое обновление ломает весь сервис.

Почему важно учитывать API-интеграции еще на этапе проектирования MVP?
MVP — это не просто тестовая версия продукта, это основа, на которой будет строиться дальнейшая система. Ошибки в архитектуре интеграций могут:
— Замедлить масштабирование и развитие продукта
— Увеличить затраты на поддержку и разработку
— Привести к сложным рефакторингам и переработке архитектуры

Как этого избежать? Использовать лучшие практики проектирования API в MVP. Давайте разберем ключевые принципы.

1️⃣ Проектируйте API снаружи внутрь

Многие команды сначала создают бизнес-логику, а API добавляют потом, «как получится». В итоге API становится неуклюжим и неудобным. Вместо этого:
— Определите, какие интеграции потребуются в будущем (например, платежи, аналитика, внешние сервисы)
— Используйте API-first подход — сначала проектируйте API, а потом код
— Документируйте API сразу (OpenAPI/Swagger)

Пример: Команда проекта по доставке еды сначала разработала базовый REST API для заказов, а потом легко подключила к нему мобильное приложение и сторонних партнеров.

2️⃣ Разделяйте внутреннее и внешнее API

Ваш API должен быть гибким и независимым. Разделяйте:
— Внешнее API (для партнеров, мобильных приложений, клиентов)
— Внутреннее API (для взаимодействия между микросервисами)

3️⃣ Делайте API версионируемым

Без версионирования API разрыв обратной совместимости неизбежен
— Вводите версионирование сразу: https://api.example.com/v1/orders
— Используйте backward-compatible изменения (добавление полей, а не изменение формата)
— Если API меняется кардинально, поддерживайте несколько версий

Пример: В стартапе финтех-решений изменение структуры JSON привело к сбоям у клиентов. После внедрения v2 API с backward compatibility бизнес избежал проблем.

4️⃣ Используйте брокеры сообщений для событийных интеграций

Если в будущем ожидается много асинхронных процессов (уведомления, аналитика, платежи), проектируйте систему сразу с событийно-ориентированной архитектурой (EDA):
— Kafka, RabbitMQ, NATS — для передачи событий между сервисами
— Webhooks — для уведомлений внешних систем

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

На курсе «Архитектура ИТ-решения: Проектирование и реализация MVP» вы изучите принципы работы веб-приложений, научитесь проектировать и реализовывать двухзвенную, трехзвенную и EDA-архитектуры на открытом стеке (PostgreSQL, Kafka, Python).

Регистрация

#курс@systems_education #проектирование@systems_education #MVP@systems_education

ГЛОССАРИЙ СИСТЕМНОГО АНАЛИТИКА ИНФОРМАЦИОННЫХ СИСТЕМ

У нас получилось собрать обширный словарь терминов, который охватывает всё, что окружает системного аналитика: от ролей в компании и методологий разработки до технических терминов интеграций. Помимо официальных терминов мы добавили разговорные, потому что вряд ли вы услышите от коллеги, что тот «выгрузил локальные изменения на сервер» — скорее всего, он лаконично «запушил».

Как его использовать?
— Новичкам в профессии или в компании глоссарий поможет быстрее сориентироваться в профессиональном жаргоне: когда слышишь что-то вроде «Владелец продукта сказал задеплоить на прод» или «надо оформить MoSCoW», открываешь нужный раздел и всё проясняется.
— Можно взять наш глоссарий за основу и опубликовать в корпоративном конфлюенсе. Во-первых, это упростит онбординг новых коллег: вместо бесконечных расспросов «А что такое рефайнмент?» есть готовый «словарь», где все слова и пояснения собраны. Во-вторых, это будет единая «точка правды»: команды часто спорят, что значат «нефункционалки» или «альтернативные потоки». Теперь им можно просто сослаться на общую договорённость из глоссария.

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

Сегодняшняя тема:
«Как мы развёртываем приложение или сервис на целевой среде»

«Развертывание» или «деплой» — процедура, с которой связан любой IT-проект. И в каждой компании своя терминология: кто-то «деплоит», кто-то «выкатывает на прод», кто-то «заливает обновления», а в ТЗ может стоять «развертывание системы на боевом сервере с учётом ограничений доступности». Короче, путаницы хватает, давайте её разберём.

Делитесь в комментариях официальными и разговорными терминами, которые использует ваша команда. Чем вы занимаетесь: «деплоите» или «выкатываете релиз»? Какая у вас бывает целевая среда: «продакшн» и «тестовый стенд»? Какими словами вы называете откат или отмену обновления? А, может, вы знаете, что такое непрерывная доставка или проброс портов?

Ждём ваши комментарии⬇️

REST API для высоконагруженных систем: как выдерживать миллионы запросов в секунду?

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

Как ускорить REST API и выдержать нагрузку?

🔹 Кэширование: не заставляйте сервер работать лишний раз
Кэширование позволяет повторно использовать ранее рассчитанные данные, не нагружая сервер.

— Кэширование на клиенте — браузеры и мобильные приложения могут хранить часто используемые данные, чтобы не делать запросы заново.
— HTTP-кэширование — заголовки Cache-Control и ETag позволяют серверам и прокси-кэшам хранить ответы.
— Redis/Memcached — серверное кэширование часто запрашиваемых данных в памяти снижает нагрузку на базу данных.

🔹 Сжатие данных: уменьшите размер ответа API
Чем меньше данных передаётся по сети, тем быстрее работает API

— Gzip, Brotli — сжатие HTTP-ответов уменьшает трафик в 3-5 раз.
— JSON без лишних полей — вместо отправки {"name": "iPhone", "price": 999, "description": "Powerful phone"} можно оставить только нужные поля.
— Binарные форматы — gRPC или Protobuf позволяют передавать данные эффективнее, чем JSON.

🔹 Пагинация: не перегружайте API ненужными данными

Без пагинации API может отдавать тысячи записей за один запрос, что приводит к:
— Долгому времени обработки
— Избыточному расходу памяти
— Перегрузке сервера

Как сделать правильно?
— Пагинация с limit и offset (/users?limit=50&offset=100)
— Курсорная пагинация — эффективнее при больших объёмах данных (/users?cursor=abcd1234)
— API, отдающее только изменённые данные (/updates?since=2024-03-10)

🔹 Асинхронные операции: не заставляйте клиентов ждать
— Очереди сообщений (RabbitMQ, Kafka, NATS) — запрос ставится в очередь, а клиент получает job_id
— Webhook’и — API отправляет уведомление, когда работа завершена
— Poll-подход — клиент периодически проверяет статус задачи (/report/status?id=123)

🔹 Балансировка нагрузки: распределите запросы по серверам

Когда запросов слишком много, одного сервера уже недостаточно. Решение — балансировка нагрузки:
— Reverse proxy (NGINX, HAProxy) — равномерно распределяет запросы между несколькими серверами
— Auto Scaling — при увеличении нагрузки автоматически добавляются новые серверы (AWS, Kubernetes)
— Rate Limiting — ограничение запросов (1000 rps на пользователя) защищает API от перегрузок и атак

На воркшопе «Проектирование интеграции с REST API» вы под руководством эксперта проанализируете процесс взаимодействия систем, потоки данных, опишете REST-like API и поймёте, как аналитик решает интеграционные задачи.

Регистрация

#воркшоп@systems_education

🛰 Дмитрий Золотухин выступит на третьей конференции Systems Design Online с докладом на тему «История переезда с Hive на ClickHouse»

Обсудим:
— Чем занимались аналитики данных в компании More. TV и почему это пришлось менять
— Разбор технического стека аналитической системы (Hadoop, Airflow, внешние SaaS-сервисы, Tableu), его проблемы и почему их нужно было срочно решать
— Сбор требований к аналитической системе, критерии выбора нового стека технологий и их выбор
— Как мы переехали на Clickhouse, Dagster, MinIO, Open Metadata FineBI, Debezium с Kafka, DBT и собственные ML-сервисы
— Что из запланированного получилось, а чего не удалось достичь и почему

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

Как распознавать и бороться с анти-паттернами в Event Storming

Event Storming — это эффективная техника для командной работы, выявления проблем, создания общего понимания сложных бизнес-процессов и проектирования систем, их поддерживающих. Она помогает «вытащить» важные события, увидеть логику взаимодействий и сформулировать ясную картину того, что происходит в компании. Однако, как и любая техника, Event Storming подвержен ошибкам, которые могут свести на нет все усилия. Ниже рассмотрим наиболее распространённые «анти-паттерны» и способы их преодоления, чтобы ваши сессии были максимально продуктивными.

Что такое анти-паттерны?
Анти-паттерны — это решения, которые выглядят разумными на первый взгляд, но приводят к негативным последствиям. В контексте Event Storming анти-паттерны мешают команде достичь цели, запутывают участников и порой даже демотивируют их. Понимание этих ловушек — первый шаг к проведению успешных сессий.

1️⃣ Хаос на доске
— Слишком много стикеров, нет чёткого порядка размещения
— Трудно отследить логику процесса, участники теряют нить повествования
— Сессия превращается в поток бессистемной информации

Способы борьбы
— Чётко определите границы: До начала сессии согласуйте, какую часть процесса вы рассматриваете (scope).
— Задавайте направляющие вопросы: Модератор (фасилитатор) может периодически напоминать, о чём идёт речь: «А как это событие влияет на итог?», «Почему оно здесь важно?».
— Используйте фильтрацию: После «выгрузки» событий на доску сгруппируйте и приоритизируйте их, чтобы оставить наиболее критичные для обсуждения.

2️⃣ Доска — личный дневник
— Один-два человека доминируют, а остальные участники молча наблюдают
— Вклад других членов команды почти не учитывается

Способы борьбы
— Активная фасилитация: Модератору важно «подсвечивать» каждую роль, задавая вопросы всем участникам
— Распределение ролей: Назначьте, к примеру, «писателя», «аналитика» и «наблюдателя», чтобы каждый внёс свой вклад
— Перерывы и общение: Небольшие паузы в работе помогают людям размяться и поделиться идеями в менее формальной обстановке

3️⃣ Непонятный язык
— Использование узкоспециализированных терминов, которые понятны лишь части аудитории
— Недопонимания приводят к искажению информации и повторным разъяснениям

Способы борьбы
— Максимальная ясность: Старайтесь формулировать события простыми словами
— Уточняйте значения: Если кто-то вводит новый термин, попросите его объяснить смысл для всех
— Фиксируйте словарь: Если термин используется часто, зафиксируйте его определение где-нибудь на доске, чтобы все говорили «на одном языке»

4️⃣ Зацикливание на деталях
— Команда уходит в обсуждение мелочей, забывая об общей картине
— Слишком много времени тратится на уточнение второстепенных моментов, прежде чем сформировано общее представление о процессе

Способы борьбы
— Начинайте с ключевых событий: Отметьте самые важные пункты и стройте повествование вокруг них
— Используйте «парковку»: Если деталь требует глубокой проработки, вынесите её на отдельную часть доски. Вернётесь к ней позже, если действительно потребуется
— Избегайте преждевременной оптимизации: В ходе Event Storming главное — увидеть всю картину процесса, а не сразу решать технические нюансы

5️⃣ «Забытые события»
— Команда выпускает из виду важные действия или роли
— Диаграмма получается неполной и может ошибочно отражать реальное состояние дел

Способы борьбы
— Визуализируйте полный цикл: Используйте таймлайны или подход «user journey», чтобы шаг за шагом пройти весь сценарий
— Задавайте вопросы «А что, если…»: Они стимулируют участников вспоминать нестандартные или редко возникающие события
— Подготовка к сессии: Соберите предварительные данные из документации, интервью с участниками процесса, исторических записей — это поможет не упустить важные моменты

Event Storming даёт возможности для «раскрытия» сложных процессов и совместной выработки решений. Для применения подхода на практике приглашаем вас пройти воркшоп: «Event Storming как техника моделирования предметной области и выявления микросервисов».

Регистрация

#воркшоп@systems_education

🚀 Третья онлайн-конференция Systems Design Online состоится уже через несколько дней

Мы соберем опытных архитекторов, аналитиков и технических лидеров, чтобы с разных сторон поговорить о Компромиссах проектирования — балансе между атрибутами качества, финансированием и сроками.

В первый день вас будут ждать более 20 докладов, а во второй — три воркшопа и два мастер-класса с акцентом на практику!

Каждая секция докладов в этом году раскрывает главную тему конференции с разных сторон:

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

📍Секция «Искусственный интеллекст и Машинное обучение» освещает современные методы и практики, позволяющие использовать потенциал данных и интеллектуальных систем в бизнесе. Участники узнают, как построить эффективный процесс обработки и анализа данных, какие подходы наиболее результативны, а также как масштабировать и проектировать решения ИИ в условиях растущей нагрузки и разнообразия бизнес-требований. Также мы затронем темы применения AI для решения задач, возникающих в процессе разработки и внедрения решений.

Билеты на конференцию, воркшопы и мастер-классы можно приобрести на сайте

Канал конференции @systems_design_online

#конференция@systems_education

📋 Требования нужны не каждому проекту!

«Где ваши требования? Почему до сих пор нет ТЗ?»
— это стандартные упрёки в сторону аналитика, особенно в первые недели проекта. Считается, что без требований нельзя проектировать, а уж тем более разрабатывать. Но что, если требования — это вовсе не обязательный элемент проекта?

В 2012 году профессор Пол Ральф ввёл в обиход термин «иллюзия требований». Он доказал: многие из того, что мы называем «требованиями», на деле оказываются целями, предпочтениями или проектными решениями.

Когда требований нет — И ЭТО НОРМАЛЬНО

Представим ситуацию. Бизнес хочет «снизить нагрузку на операторов». Мы можем достичь этой цели совершенно разными путями:
— внедрить чат-бота
— автоматизировать документооборот
— перераспределить звонки между отделами

Каждое решение — это совершенно разный путь. Пока мы не выбрали, как именно достигнем цели, — говорить о «требованиях» рано. Их просто нет. Есть только цель и множество гипотез.

И вот тут аналитик часто попадает в ловушку: он начинает оформлять конкретное проектное решение (например, «добавить чат-бота с тремя ветками диалогов») как «требование». А значит, сужает пространство решений. Мы как бы утверждаем: «по-другому нельзя», хотя это не так.

На курсе «Системный анализ. Разработка требований в ИТ-проектах» мы разбираем:
— как отличить реальные требования от решений и предположений
— как действовать в условиях высокой неопределённости
—как вести проект без «иллюзии требований»

Подробнее о курсе

#курс@systems_education #системный_анализ@systems_education

💰Сейчас самое выгодное время, чтобы зарегистрироваться на летний поток «Systems Analyst Bootcamp».
И это не шутка!

12 апреля будет второе повышение цен на программу переподготовки. Буткемп подойдёт тебе, если ты уже давно рассматриваешь профессию СА, хочешь быстрый карьерный старт или не первый месяц борешься с «синдромом самозванца».

За 3 месяца обучения вы познакомитесь с реальными задачами системного аналитика, поработав с заказчиком над практическим проектом.

Каждую неделю вас будут ждать:
— Два четырехчасовых воркшопа для получения теоретических знаний и практических умений
— Двухчасовая встреча-созвон с Заказчиком
— Встреча-созвон с командой для выполнения совместных заданий
— Отработка теоретического материала на обучающей платформе
— Выполнение индивидуальных домашних заданий и предоставление их на проверку
— Ведение документации в рабочем пространстве команды

Подробнее ознакомиться с программой буткемпа вы можете тут

#буткемп@systems_education

🛰 Антон Давыдов, Solution architect и Разработчик, выступит на третьей конференции Systems Design Online с докладом на тему «Как предсказать “будущее” системы (почти)»

О докладе:
Работая над проектом, хочется предсказать, что будет с ним в будущем. И благодаря таким предсказаниям заранее «подложить солому», подготавливая код к преедсказанным изменениям. Например, можно предположить, что стоит заранее вынести сервис из монолита прямо сейчас, а через пару месяцев понять, что сервис не нужен бизнесу. Либо запариться с оптимизацией кода или новым языком в компании, а вместо этого окажется, что бизнесу важнее быстрое появление новых фичей в проекте.

На деле, подобные предсказания могут сильно отличаться от действительности, так как для предсказания учитывается не весь контекст, а только технический. Либо вообще предсказывают по наитию, либо «потому что так сделали в другой компании».

В своем докладе Антон расскажет о том, как уйти от предсказания развития проекта «пальцем в небо» и не скатиться в хардкорные аналитические подходы. Вместо этого воспользуемся концепциями из системной инженерии и теории систем, чтобы собрать как можно больше информации о системе. Благодаря этому получим примерные «границы», в которых может развиваться система, чем улучшим «предсказательный» навык в команде.

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

5 апреля (сб) в 18:00 МСК пройдет вебинар на тему «AI-управляемые архитектуры данных в корпоративных системах», на котором вы узнаете, как проектировать и внедрять архитектуры ИИ в реальном времени с использованием событийного подхода, стриминга и современных инструментов.

Проведёт вебинар Денис Прилепский, специалист с более чем 15 годами опыта в сфере технологий и ИИ в рамках внутренних и внешних проектов для крупнейших компаний в финансовом секторе, добывающей промышленности, потребительских товаров и телекоммуникаций.

▫️План вебинара:
1. Зачем бизнесу ИИ в реальном времени
2. Архитектура потока данных с ИИ
3. Паттерны архитектуры: Lambda, Kappa
4. Технологии, инструменты и ключевые блоки (Kafka, Flink/Spark, Feature Store, Model Serving, аналитика)
5. Оптимизация и надёжность
6. Практические принципы проектирования
7. Выводы и рекомендации
8. Ответы на вопросы


▫️Кому будет полезен вебинар?
— ИТ-архитекторам и руководителям разработки, которые планируют или реализуют проекты с real-time аналитикой и ИИ
— Руководителям ИТ и цифровых трансформаций, интересующимся практическим применением ИИ в бизнес-процессах
— Бизнес-аналитикам и product-менеджерам, которым важно понимать, как архитектурные решения влияют на скорость и эффективность ИИ-систем.

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

Регистрация

❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.

#вебинар@systems_education

🎥 Выложили запись доклада Дмитрия Пахомова с конференции Systems Design 24 на тему «Проектирование эффективной системы кэширования»

Архитектор Дмитрий Пахомов рассмотрел ключевые аспекты, включая классификацию, мониторинг и решение проблем, таких как дублирование запросов, недоступность данных и влияние тайм-аутов на наполнение кэша. Основное внимание уделено оптимизации производительности и устойчивости системы в условиях сбоев.

Тайм-код доклада:
00:00 О докладе
01:11 Пример приложения
02:39 Что такое кэширование?
04:02 Классификация
07:35 Application cache
10:45 Мониторинг
13:45 Проблема 1: Дублирование запросов в полёте
18:03 Проблема 2: Недоступность данных во время сбоя
21:44 Проблема 3: Timeout мешает наполнению кэша
25:43 Итог

Посмотреть можно на нашем You-Tube канале

🚀 12-13 апреля состоится третья конференция Systems Design Online

Конференция Systems Design Online будет интересна:
— разработчикам и аналитикам
— архитекторам и руководителям ИТ-проектов
— всем, кто стремится повышать эффективность бизнес-процессов при помощи современных технологических решений

Подробнее о конференции здесь
Канал конференции @systems_design_online

#выступления@systems_education

Онлайн-курс «Системное моделирование. Проектирование информационных систем с помощью UML»

Вас ждут 4 занятия по 4 часа (по субботам)

🔹Когда?
17 Мая — 7 Июня

🔹Для кого полезен курс?
— Системных и бизнес-аналитиков, которые хотят улучшить навыки визуализации и фиксации требований с помощью UML-диаграмм
— Системных аналитиков и проектировщиков, желающих эффективно проектировать архитектуру и взаимодействия в программных системах
— Тестировщиков и технических писателей, стремящихся глубже понять процессы и состояния систем для создания более точной документации
— Менеджеров проектов и продакт-менеджеров, цель которых — лучше понять процессы разработки и развертывания для успешного управления проектами
— Начинающих ИТ-специалистов, желающих освоить универсальный инструмент для моделирования и анализа систем

🔹Вы научитесь:
— Определять, когда использовать объектно-ориентированный, а когда — структурный подход к описанию процессов и систем
— Выбирать наиболее подходящую UML-диаграмму для описания конкретного артефакта при разработке требований к ПО, описании процессов и систем
— Описывать структуру и поведение информационных систем и бизнес-процессов в виде наглядных и понятных UML-диаграмм
— Говорить с разработчиками на одном языке
— Эффективно применять инструментарий UML в реальных задачах бизнес- и системного анализа, от описания требований до разработки программной документации (ТЗ, спецификация требований, руководство пользователя и администратора)
— Пользоваться облачными редакторами для разработки UML-диаграмм

Регистрация

#курс@systems_education #UML@systems_education

На Третьей конференции Systems Design Online 13 апреля пройдут два мастер-класса

Тема конференции в этом году — «Компромиссы проектирования — баланс между атрибутами качества, финансированием и сроками». Все воркшопы и мастер-классы помогут участникам быстро освоить умения, необходимые для проектирования эффективных информационных систем.

Подробнее о мастер-классах конференции:

1️⃣ Архитектурные решения и AI

За 2 часа вы узнаете:
— О разных способах применения больших языковых моделей
— Как анализировать текущие архитектурные решения
— Как анализировать архитектурные схемы с помощью LLM
— Как создавать документацию к архитектурным решениям
Подробнее о мастер-классе

2️⃣ Тестирование архитектуры программного обеспечения
Бесплатный для всех участников конференции

Будет особенно полезен:
— Разработчикам микросервисных систем
— Junior-архитекторам
— Бэкенд-разработчикам, которые хотят перейти в архитектуру
— Системным аналитикам
— Архитекторам

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

🛰 Олег Гришко, Главный ИТ-Архитектор с опытом более 20 лет, выступит на третьей конференции Systems Design Online с докладом на тему «Построение платформы данных»

Обсудим:
— Trade-offы и возможные компромиссы при создании платформы
— Как довести начатое до конца, чтобы все остались довольны

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

Воркшоп «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку»

🔹 Когда?
с 24 мая (сб)

Цель обучения — научиться описывать постановку задачи на разработку ИТ-системы, сервиса, продукта в понятной, однозначной, наглядной форме, не залезая в детали реализации.

Воркшоп подойдёт тем, кому важно уметь ставить задачи на разработку ИТ-систем и сервисов:
— бизнес-аналитикам
— Product Owner
— менеджерам продукта и проекта

🔹 Чему Вы научитесь?
— Как определять состав продукта, исходя из целей
— Как проводить декомпозицию историй продукта
— Как приоритизировать бэклог
— Как писать хорошие истории
— Как создавать план развития продукта

Подробнее о программе воркшопа можно узнать тут!

#Agile

BPMN vs. Event Storming: что выбрать и когда?

1. Что такое BPMN?
BPMN — графический нотационный стандарт для описания бизнес-процессов.
— Цель: показать, как выполняются процессы (задачи, события, шлюзы), какие ресурсы участвуют и где принимаются решения.

➕ Плюсы: строгая нотация, возможность запускать диаграммы на выполнение, единый стандарт, популярность.
❗️ Минусы: трудно вносить изменения, требует глубокого знания / понимания нотации, может оказаться сложным в обучении и громоздким для больших процессов; ориентирован в основном на уже формализованные схемы.

2. Что такое Event Storming?
Event Storming — «мозговой штурм» в стиле DDD, основанный на выявлении ключевых событий и правил с помощью построения диаграммы из стикеров и совместного обсуждения.
— Цель: быстро «вытащить» из экспертов, что происходит в процессе, какие команды инициируют события и каковы основные бизнес-правила.

➕ Плюсы: легкость в изучении нотации, не содержит строгих элементов нотациию, простота построения и внесения изменений, вовлекает всю команду, гибок, легко выявляет пробелы в понимании.
❗️ Минусы: не подходит для документирования процессов и результатов проектирования, сильно зависит от фасилитатора, труден при очень большом количестве участников.

3. Как выбрать подход?
— Нужно формально описать уже известный процесс: используйте BPMN.
— Только изучаете область: Event Storming быстрее раскрывает ключевые идеи и болевые точки.
— Нужен быстрый результат: Event Storming стартует проще, BPMN даёт надежный способ сохранения результатов.
— Необходимы формальные регламенты и аудит: BPMN предпочтительнее как официальный стандарт.
— Требуется командная сессия для генерации идей: Event Storming вовлекает стейкхолдеров, даже без технических навыков.

4. Можно ли совмещать BPMN и Event Storming?
— Сначала с помощью Event Storming выясняют «карту» домена, события и цепочки действий, а также фиксируют суть процесса и его участников
— Затем ключевые процессы оформляют в BPMN, чтобы зафиксировать процесс для передачи далее в проектирование и разработку.

Таким образом, Event Storming помогает «раскрыть» глубину домена, а BPMN даёт формальную нотацию для внедрения и документирования процессов.

Научиться моделированию бизнес-процессов и эффективному использованию BPMN можно на нашем воркшопе «BPMN для людей: основы самой популярной нотации для описания бизнес-процессов».
Регистрация

Если вас интересует применение подхода Event Storming на практике, то регистрируйтесь на воркшоп: «Event Storming как техника моделирования предметной области и выявления микросервисов».
Регистрация

#воркшоп@systems_education

Воркшоп «Проектирование DWH по методологии Data Vault»

🔹Когда старт?
16 апреля

Data Vault, методология проектирования DWH, проще якорной модели (Anchor Modeling), но также обладает высокой гибкостью и лучше поддается дополнению и расширению по сравнению с классическими звёздными схемами по Кимбалу и Инмону.

🔹Цель обучения
На воркшопе мы спроектируем схему хранилища данных по методологии Data Vault. Последовательно пройдём 5 шагов: от концептуальной модели предметной области до табличной схемы, определив источники данных, бизнес-ключи для хабов и их контекстные свойства в таблицах-спутниках.

🔹На воркшопе будет групповая работа по кейсам: Банк, Служба доставки, Служба такси.

🔹Воркшоп для
системных аналитиков, которые хотят познакомиться с правилами и принципами организации корпоративного хранилища данных, а также подходами и технологиями, позволяющими их реализовать.

Регистрация

#воркшоп@systems_education

На Третьей конференции Systems Design Online 13 апреля пройдет онлайн-воркшоп на тему «Принятие и документирование архитектурных решений»

Воркшоп будет особенно полезен:
— Системным аналитикам уровня Middle- (и выше)
— Специалистам, которые занимаются проектированием и интеграцией сервисов
— Архитекторам решений

На воркшопе участники научатся:
— Осознанно подходить к проектированию решений
— Фиксировать архитектурные решения, используя ADR (Architectural Decision Records)
— Работать с несколькими вариантами архитектурных решений, анализировать их плюсы и минусы

Программа воркшопа:

1️⃣ Введение 
— Знакомство, цели воркшопа
— Краткий разбор ADR и его ценности

2️⃣ Первая итерация
— Участники работают в группах, решают задачу
— Оформляют архитектурные решения

3️⃣ Разбор первой итерации
— Группы меняются результатами
— Анализируют чужие решения, вносят правки

4️⃣ Вторая итерация
— Уточнение и адаптация решений
— Документирование принятых решений

5️⃣ Финальный разбор
— Обсуждение типичных проблем
— Выводы, рекомендации

Оплатить воркшоп можно по ссылке
Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education