Неочевидные риски в проектировании API и как их минимизировать 👀
Практически любая крупная система обменивается данными с другими сервисами или предоставляет к себе доступ через программный интерфейс. Однако при проектировании API легко попасть в «ловушки», которые изначально кажутся несущественными, но в будущем оборачиваются проблемами для масштабирования, безопасности и удобства использования.
⬆️ На карточках разобрали несколько неочевидных рисков и способы их минимизации.
Если вы позаботитесь о каждом из перечисленных пунктов, ваш API будет обладать надёжной архитектурой, ориентированной на будущее. А главное — потребители (и вы сами) не столкнутся с «подводными камнями», которые могут стоить слишком дорого, когда ваша платформа начнёт масштабироваться. Если у вас еще нет опыта проектирования сложных API, мы приглашаем вас принять участние в одноименном воркшопе, где вы на практике познакомитесь с OpenAPI и AsyncAPI.
Регистрация
#API #OpenAPI #AsyncAPI #воркшоп
Практически любая крупная система обменивается данными с другими сервисами или предоставляет к себе доступ через программный интерфейс. Однако при проектировании API легко попасть в «ловушки», которые изначально кажутся несущественными, но в будущем оборачиваются проблемами для масштабирования, безопасности и удобства использования.
⬆️ На карточках разобрали несколько неочевидных рисков и способы их минимизации.
Если вы позаботитесь о каждом из перечисленных пунктов, ваш API будет обладать надёжной архитектурой, ориентированной на будущее. А главное — потребители (и вы сами) не столкнутся с «подводными камнями», которые могут стоить слишком дорого, когда ваша платформа начнёт масштабироваться. Если у вас еще нет опыта проектирования сложных API, мы приглашаем вас принять участние в одноименном воркшопе, где вы на практике познакомитесь с OpenAPI и AsyncAPI.
Регистрация
#API #OpenAPI #AsyncAPI #воркшоп
🔥10👍4
Какие диаграммы UML наиболее востребованы в 2025 году?
На первый взгляд может показаться, что UML как «классический» язык моделирования теряет актуальность, но на практике всё происходит ровно наоборот – UML трансформируется в удобный язык междисциплинарной коммуникации. Однако не все диаграммы UML являются однозначным must have для аналитика в 2025 году.
⬆️ На карточках выделили самые востребованные диаграммы в 2025 году
На курсе «Системное моделирование. Основы ООП и разработка UML-моделей» вы под руководством опытного эксперта познакомитесь с 8 UML-моделями и на практике закрепите полученные умения.
Регистрация
#курс #UML
На первый взгляд может показаться, что UML как «классический» язык моделирования теряет актуальность, но на практике всё происходит ровно наоборот – UML трансформируется в удобный язык междисциплинарной коммуникации. Однако не все диаграммы UML являются однозначным must have для аналитика в 2025 году.
⬆️ На карточках выделили самые востребованные диаграммы в 2025 году
На курсе «Системное моделирование. Основы ООП и разработка UML-моделей» вы под руководством опытного эксперта познакомитесь с 8 UML-моделями и на практике закрепите полученные умения.
Регистрация
#курс #UML
🔥7❤2👍1
Как диаграммы последовательностей облегчают работу с API и микросервисами
Как не потеряться в сложном взаимодействии десятков сервисов при работе с микросервисами и открытыми API? Один из самых наглядных инструментов для этого — диаграммы последовательностей. Ниже расскажем, как они помогают командам и приведём конкретные примеры.
1️⃣ Быстрый старт и визуализация логики
Представьте, что ваш новый разработчик спрашивает: «Почему сервис аутентификации выдает токен, а затем сервис каталога товаров вызывает сервис оплаты?» Вместо многостраничной документации вы показываете диаграмму последовательностей — и всё становится прозрачно в считанные минуты.
📍Пример: В ритейл-проекте диаграмма показывает, как пользователь авторизуется, получает данные товаров, оформляет заказ, а система оплаты связывается с банком. Без лишних слов всё на виду.
2️⃣От архитектурной идеи к конкретному коду
Sequence Diagram помогает детализировать цепочку вызовов: что именно «дергается» первым и какие параметры передаются на каждом шаге.
📍Пример: В финтех-проектах видно, что после получения запроса на перевод сервис обработки платежей вызывает службу верификации, а та — внешний сервис антифрода. Любая ошибка или несоответствие форматов сразу бросаются в глаза.
3️⃣ Коммуникация внутри команды
Аналитики, тестировщики, разработчики интерфейсов — у всех свой взгляд на систему. Диаграммы последовательностей работают как универсальный «переводчик».
📍Пример: В проекте по онлайн-образованию тестировщик видит, что после нажатия «Сдать тест» система должна не только записать результат, но и уведомить почтовый сервис о необходимости отправить сертификат. Все знают свой участок работы и не мешают друг другу.
4️⃣ Предупреждение интеграционных ошибок
В сложных интеграциях легко упустить мелочь — например, один сервис ждёт JSON, а другой отдаёт XML. На диаграмме такие расхождения сразу заметны.
📍Пример: В электронной медкарте к сервису результатов анализов добавили новый формат отчётов, но забыли настроить сервис уведомлений. Диаграмма своевременно подсветила этот «пробел», не дожидаясь жалоб от врачей и пациентов.
5️⃣ «Живая» документация
Микросервисы эволюционируют, меняются форматы API, добавляются новые модули. Если держать диаграмму в актуальном состоянии, она станет первым местом, куда смотрят все новые участники проекта.
📍Пример: В системе для управления складом каждый месяц появляются новые методы проверки остатков. Добавляя их в диаграмму, команда мгновенно понимает, как эти изменения повлияют на сборку заказов, логистику и отчётность.
Диаграммы последовательностей — не просто красивые схемы, а мощный инструмент для упрощения интеграции и снижения рисков. Если вы хотите строить их эффективно и корректно, мы приглашаем вас на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования».
Регистрация
#воркшоп #UML
Как не потеряться в сложном взаимодействии десятков сервисов при работе с микросервисами и открытыми API? Один из самых наглядных инструментов для этого — диаграммы последовательностей. Ниже расскажем, как они помогают командам и приведём конкретные примеры.
1️⃣ Быстрый старт и визуализация логики
Представьте, что ваш новый разработчик спрашивает: «Почему сервис аутентификации выдает токен, а затем сервис каталога товаров вызывает сервис оплаты?» Вместо многостраничной документации вы показываете диаграмму последовательностей — и всё становится прозрачно в считанные минуты.
📍Пример: В ритейл-проекте диаграмма показывает, как пользователь авторизуется, получает данные товаров, оформляет заказ, а система оплаты связывается с банком. Без лишних слов всё на виду.
2️⃣От архитектурной идеи к конкретному коду
Sequence Diagram помогает детализировать цепочку вызовов: что именно «дергается» первым и какие параметры передаются на каждом шаге.
📍Пример: В финтех-проектах видно, что после получения запроса на перевод сервис обработки платежей вызывает службу верификации, а та — внешний сервис антифрода. Любая ошибка или несоответствие форматов сразу бросаются в глаза.
3️⃣ Коммуникация внутри команды
Аналитики, тестировщики, разработчики интерфейсов — у всех свой взгляд на систему. Диаграммы последовательностей работают как универсальный «переводчик».
📍Пример: В проекте по онлайн-образованию тестировщик видит, что после нажатия «Сдать тест» система должна не только записать результат, но и уведомить почтовый сервис о необходимости отправить сертификат. Все знают свой участок работы и не мешают друг другу.
4️⃣ Предупреждение интеграционных ошибок
В сложных интеграциях легко упустить мелочь — например, один сервис ждёт JSON, а другой отдаёт XML. На диаграмме такие расхождения сразу заметны.
📍Пример: В электронной медкарте к сервису результатов анализов добавили новый формат отчётов, но забыли настроить сервис уведомлений. Диаграмма своевременно подсветила этот «пробел», не дожидаясь жалоб от врачей и пациентов.
5️⃣ «Живая» документация
Микросервисы эволюционируют, меняются форматы API, добавляются новые модули. Если держать диаграмму в актуальном состоянии, она станет первым местом, куда смотрят все новые участники проекта.
📍Пример: В системе для управления складом каждый месяц появляются новые методы проверки остатков. Добавляя их в диаграмму, команда мгновенно понимает, как эти изменения повлияют на сборку заказов, логистику и отчётность.
Диаграммы последовательностей — не просто красивые схемы, а мощный инструмент для упрощения интеграции и снижения рисков. Если вы хотите строить их эффективно и корректно, мы приглашаем вас на воркшоп «UML-диаграммы последовательности для аналитика: ликбез и примеры использования».
Регистрация
#воркшоп #UML
systems.education
UML-диаграммы последовательности для аналитика: ликбез и примеры использования
Sequence диаграммы UML часто применяются командами разработки и позволяют описать поведение частей любой системы и понять связи между модулями и интеграциями в ней.
👍5
Опубликовали запись вебинара на тему «AI в помощь: построение популярных диаграмм с помощью ChatGPT», на котором Яна Паршина, менеджер системного анализа и Product Manager в компании Х5 Tech, рассказала, как использовать ChatGPT для создания диаграмм, которые упрощают работу с данными, процессами и архитектурой. Мы показали, как с помощью AI можно быстро генерировать визуализации, подходящие для разных целей и ролей.
Тайм-код вебинара:
00:00 Введение
01:31 Что нам нужно. Информация на вход и необходимые навыки
04:29 Диаграммы для БА/РО. Use case. User Journey
08:50 Диаграммы для СА. Class diagram. Sequence diagram. ERD. C4
15:50 Как улучшить диаграммы. Полезные советы
16:49 Итоги. Какие инструменты использовать
20:46 Вопросы зрителей
Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК
📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.
✍️ Ссылки на курсы, которые могут быть вам полезны:
— Основы ООП и разработка UML-моделей
— UML-диаграммы последовательности для аналитика: ликбез и примеры использования
— Системный анализ. Разработка требований в ИТ-проекта
Тайм-код вебинара:
00:00 Введение
01:31 Что нам нужно. Информация на вход и необходимые навыки
04:29 Диаграммы для БА/РО. Use case. User Journey
08:50 Диаграммы для СА. Class diagram. Sequence diagram. ERD. C4
15:50 Как улучшить диаграммы. Полезные советы
16:49 Итоги. Какие инструменты использовать
20:46 Вопросы зрителей
Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК
📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.
✍️ Ссылки на курсы, которые могут быть вам полезны:
— Основы ООП и разработка UML-моделей
— UML-диаграммы последовательности для аналитика: ликбез и примеры использования
— Системный анализ. Разработка требований в ИТ-проекта
YouTube
AI в помощь: построение популярных диаграмм с помощью ChatGPT • Яна Паршина
Яна Паршина, менеджер системного анализа и Product Manager в компании Х5 Tech, в вебинаре рассказала, как использовать ChatGPT для создания диаграмм, которые упрощают работу с данными, процессами и архитектурой. Мы показали, как с помощью AI можно быстро…
👍5🔥2❤1
HTTP vs REST: почему их часто путают и чем это может быть полезно вам?
Вам наверняка приходилось слышать: «REST — это же просто HTTP-запросы в JSON!». Или встречать в технических документах что-то вроде «наш RESTful-сервис» и задумываться, действительно ли он соответствует принципам REST. Откуда берётся вся эта путаница и как она влияет на проектирование систем?
Давайте разберёмся! ⬇️
HTTP отвечает за то, как именно данные передаются по сети. Проще говоря, это «почтовая служба», которая доставляет ваше «письмо» (запрос) от клиента к серверу и обратно. У HTTP есть свои «глаголы» (GET, POST, PUT, DELETE и др.), которые чётко регламентируют, какие действия вы совершаете над ресурсом.
REST определяет принципы, чтобы ваша система оставалась:
— Масштабируемой (можно добавить больше серверов при росте нагрузки)
— Производительной (минимизация лишних запросов через кэширование)
— Отказоустойчивой
— Гибкой для изменений
— Удобной в поддержке
В основе REST лежат шесть ключевых ограничений (клиент-сервер, stateless, кэширование, единообразие интерфейса с HATEOAS, слоистая архитектура, «код по требованию»). Если хоть одно (кроме «кода по требованию») не соблюдается — это уже не будет истинным REST.
Как они связаны?
HTTP чаще всего используют, чтобы воплотить REST-принципы на практике, ведь его глаголы идеально ложатся на идею «ресурса и действий над ним». Но REST не ограничивается одним только HTTP — это общий стиль взаимодействия компонентов в распределённой системе. Можно применять и другие «транспорты» — например, очереди (MQ) или FTP.
Зачем вам это знать?
1. Не терять время на споры. Когда кто-то говорит «REST-сервис», уточните, что конкретно имеется в виду. Для одних REST — это просто использование HTTP + JSON, для других — строгие требования к stateless, кэшированию и HATEOAS.
2. Проектировать «по уму». Понимание принципов REST помогает выбирать нужную архитектуру — особенно если важны масштабируемость и стабильность.
3. Упрощать жизнь команде. Согласованность в том, что считать «правильным REST», избавляет от конфликтов и переделок в середине проекта.
Хотите проектирование интеграции с REST API? Приглашаем вас принять участие в одноимённом воркшопе, где вы всего за 8 часов научитесь проектировать интеграцию «с нуля».
Регистрация
Вам наверняка приходилось слышать: «REST — это же просто HTTP-запросы в JSON!». Или встречать в технических документах что-то вроде «наш RESTful-сервис» и задумываться, действительно ли он соответствует принципам REST. Откуда берётся вся эта путаница и как она влияет на проектирование систем?
Давайте разберёмся! ⬇️
HTTP — это протокол
HTTP отвечает за то, как именно данные передаются по сети. Проще говоря, это «почтовая служба», которая доставляет ваше «письмо» (запрос) от клиента к серверу и обратно. У HTTP есть свои «глаголы» (GET, POST, PUT, DELETE и др.), которые чётко регламентируют, какие действия вы совершаете над ресурсом.
REST — это архитектурный стиль
REST определяет принципы, чтобы ваша система оставалась:
— Масштабируемой (можно добавить больше серверов при росте нагрузки)
— Производительной (минимизация лишних запросов через кэширование)
— Отказоустойчивой
— Гибкой для изменений
— Удобной в поддержке
В основе REST лежат шесть ключевых ограничений (клиент-сервер, stateless, кэширование, единообразие интерфейса с HATEOAS, слоистая архитектура, «код по требованию»). Если хоть одно (кроме «кода по требованию») не соблюдается — это уже не будет истинным REST.
Как они связаны?
HTTP чаще всего используют, чтобы воплотить REST-принципы на практике, ведь его глаголы идеально ложатся на идею «ресурса и действий над ним». Но REST не ограничивается одним только HTTP — это общий стиль взаимодействия компонентов в распределённой системе. Можно применять и другие «транспорты» — например, очереди (MQ) или FTP.
Зачем вам это знать?
1. Не терять время на споры. Когда кто-то говорит «REST-сервис», уточните, что конкретно имеется в виду. Для одних REST — это просто использование HTTP + JSON, для других — строгие требования к stateless, кэшированию и HATEOAS.
2. Проектировать «по уму». Понимание принципов REST помогает выбирать нужную архитектуру — особенно если важны масштабируемость и стабильность.
3. Упрощать жизнь команде. Согласованность в том, что считать «правильным REST», избавляет от конфликтов и переделок в середине проекта.
Хотите проектирование интеграции с REST API? Приглашаем вас принять участие в одноимённом воркшопе, где вы всего за 8 часов научитесь проектировать интеграцию «с нуля».
Регистрация
systems.education
■ Онлайн-воркшоп. Проектирование интеграции с REST API
Вы проанализируете процесс взаимодействия систем, потоки данных и опишете REST-like API. Поймете, как аналитик решает интеграционные задачи. Подготовите шаблон с полным описанием процесса интеграции
❤10👍3
Кто отвечает за качество требований: аналитик, разработчик или заказчик?
Когда речь заходит о качестве требований, все коллеги сразу указывает на аналитика. Мол, он и пишет, значит именно он и отвечает. Но в реальности картина куда многограннее. Разработанные требования — это коллективный продукт, и в идеале над ним работают аналитик, разработчик, заказчик (а порой и конечные пользователи). Разберём, почему важно участие всех этих ролей и как совместная ответственность улучшает результат.
👨💻 Роль аналитика
Аналитик в первую очередь занимается функциональным проектированием: формирует четкую структуру будущего решения, увязывая бизнес-цели и технические ограничения. Он не просто собирает данные, а активно определяет логику работы системы, проводит интервью с заказчиком и фасилитирует встречи с командой, чтобы вместе прийти к оптимальному варианту. Ключевая задача аналитика — выстроить сквозную концепцию с учетом существующих процессов и правил, одновременно проверяя реалистичность и согласованность требований.
Однако аналитик — не всемогущий «хранитель всех знаний», он фасилитатор, который открыто обсуждает, уточняет и согласовывает детали, подтягивая нужных специалистов.
🧑🔧 Роль разработчика
Разработчик знает, как именно будут реализованы требования: какую технологию лучше применить, какие есть ограничения платформы, что будет стоить слишком дорого в плане времени и ресурсов. Без его мнения легко добавить в требования сложные фичи, которые потом «не влезут» в сроки или выбьют бюджет.
Задача разработчика — активно участвовать в обсуждении и подтверждать, что предлагаемая функциональность реализуема и разумна с технической точки зрения. Также он вносит свой вклад в формализацию требований: определяет, какие данные и в каком формате нужны, как будет взаимодействовать фронт- и бэкенд, какие есть риски. Если разработчик отмалчивается, а позже говорит «это сделать нельзя» или «слишком дорого», то проект теряет время и деньги.
👨💼 Роль заказчика
Без участия заказчика мы можем лишь гадать о бизнес-целях, приоритетах и критериях «хорошо/плохо». Заказчик определяет, чего он хочет достичь с помощью будущей системы: какие задачи решить, какие проблемы закрыть. Часто у него есть уникальные доменные знания — как устроены бизнес-процессы, кто из пользователей чем занимается.
Важно вовлекать заказчика не только на старте (когда формулируются цели), но и в процессе уточнения деталей. Заказчик должен подтверждать: «Да, мы действительно хотим именно такой функционал», «Нет, это уже лишнее».
Качество требований — это общая ответственность. Аналитик инициирует процесс, организует информацию и обеспечивает методическую корректность. Разработчик помогает проверять идею на техническую реальность. Заказчик и пользователи определяют бизнес-ценность и вносят изменения по мере уточнения деталей.
На нашем курсе «Системный анализ. Разработка требований в ИТ-проектах» вы научитесь правильно работать с разработчиками и заказчиками и на практических примерах освоите 10 техник выявления, формулирования и анализа требований к программам.
Регистрация
#курс #системный_анализ
Когда речь заходит о качестве требований, все коллеги сразу указывает на аналитика. Мол, он и пишет, значит именно он и отвечает. Но в реальности картина куда многограннее. Разработанные требования — это коллективный продукт, и в идеале над ним работают аналитик, разработчик, заказчик (а порой и конечные пользователи). Разберём, почему важно участие всех этих ролей и как совместная ответственность улучшает результат.
👨💻 Роль аналитика
Аналитик в первую очередь занимается функциональным проектированием: формирует четкую структуру будущего решения, увязывая бизнес-цели и технические ограничения. Он не просто собирает данные, а активно определяет логику работы системы, проводит интервью с заказчиком и фасилитирует встречи с командой, чтобы вместе прийти к оптимальному варианту. Ключевая задача аналитика — выстроить сквозную концепцию с учетом существующих процессов и правил, одновременно проверяя реалистичность и согласованность требований.
Однако аналитик — не всемогущий «хранитель всех знаний», он фасилитатор, который открыто обсуждает, уточняет и согласовывает детали, подтягивая нужных специалистов.
🧑🔧 Роль разработчика
Разработчик знает, как именно будут реализованы требования: какую технологию лучше применить, какие есть ограничения платформы, что будет стоить слишком дорого в плане времени и ресурсов. Без его мнения легко добавить в требования сложные фичи, которые потом «не влезут» в сроки или выбьют бюджет.
Задача разработчика — активно участвовать в обсуждении и подтверждать, что предлагаемая функциональность реализуема и разумна с технической точки зрения. Также он вносит свой вклад в формализацию требований: определяет, какие данные и в каком формате нужны, как будет взаимодействовать фронт- и бэкенд, какие есть риски. Если разработчик отмалчивается, а позже говорит «это сделать нельзя» или «слишком дорого», то проект теряет время и деньги.
👨💼 Роль заказчика
Без участия заказчика мы можем лишь гадать о бизнес-целях, приоритетах и критериях «хорошо/плохо». Заказчик определяет, чего он хочет достичь с помощью будущей системы: какие задачи решить, какие проблемы закрыть. Часто у него есть уникальные доменные знания — как устроены бизнес-процессы, кто из пользователей чем занимается.
Важно вовлекать заказчика не только на старте (когда формулируются цели), но и в процессе уточнения деталей. Заказчик должен подтверждать: «Да, мы действительно хотим именно такой функционал», «Нет, это уже лишнее».
Качество требований — это общая ответственность. Аналитик инициирует процесс, организует информацию и обеспечивает методическую корректность. Разработчик помогает проверять идею на техническую реальность. Заказчик и пользователи определяют бизнес-ценность и вносят изменения по мере уточнения деталей.
На нашем курсе «Системный анализ. Разработка требований в ИТ-проектах» вы научитесь правильно работать с разработчиками и заказчиками и на практических примерах освоите 10 техник выявления, формулирования и анализа требований к программам.
Регистрация
#курс #системный_анализ
Substack
10 основных техник для разработки требований к ПО
BABOK предлагает порядка 50 техник для работы бизнес-аналитика.
❤12👍3
Выложили запись доклада Тимура Батыршина с конференции Systems Design 24
Доклад Тимура, руководителя направления DevOps в Axenix, на тему «Построение модели грейдов через моделирование цепочек добавленной ценности», в котором он рассказывает о процессе построения потока добавленной ценности, назначении проектных ролей, описании грейдов, а также представляет результаты создания модели на примере
Тайм-код доклада:
00:00 Тема доклада
00:47 О спикере
01:27 Актуальность проектирования и её проблемы
05:05 Проектирование через построение потока добавленной ценности
19:32 Назначение проектных ролей и распределение ответственности
24:33 Описание грейдов и компетенций
33:05 Результаты создания модели
Посмотреть можно как на нашем You-Tube канале, так и в группе в ВК
#выступления
Доклад Тимура, руководителя направления DevOps в Axenix, на тему «Построение модели грейдов через моделирование цепочек добавленной ценности», в котором он рассказывает о процессе построения потока добавленной ценности, назначении проектных ролей, описании грейдов, а также представляет результаты создания модели на примере
Тайм-код доклада:
00:00 Тема доклада
00:47 О спикере
01:27 Актуальность проектирования и её проблемы
05:05 Проектирование через построение потока добавленной ценности
19:32 Назначение проектных ролей и распределение ответственности
24:33 Описание грейдов и компетенций
33:05 Результаты создания модели
Посмотреть можно как на нашем You-Tube канале, так и в группе в ВК
#выступления
VK Видео
Построение модели грейдов через моделирование цепочек добавленной ценности • Тимур Батыршин
Докладчик конференции Systems Design 2024 и руководитель направления DevOps в Axenix рассказывает о процессе построения потока добавленной ценности, назначении проектных ролей, описании грейдов, а также представляет результаты создания модели на примере.…
🤩 Представьте: бизнес и разработчики говорят на одном языке, требования понятны, задачи четко сформулированы, а проект движется как по маслу!
Если часто слышите от бизнеса: «Мы же это не так представляли»? Или от разработчиков: «А почему нам это раньше не сказали?» — это говорит о классических симптомах проблем с пониманием и коммуникацией.
Существует решение, способное навести порядок и выстроить эффективную коммуникацию. Это Event Storming — признанная техника, предназначенная для синхронизации всех элементов проекта. Она позволяет визуализировать процессы автоматизации, улучшения бизнеса, выявлять скрытые проблемы и формировать общее понимание среди всех участников.
Event Storming — это метод совместного моделирования, который вовлекает в процесс всех заинтересованных лиц, от разработчиков до представителей бизнеса. Благодаря визуализации бизнес-процессов и выявлению ключевых событий, формируется целостное представление о системе и ее потребностях.
Хотите научиться использовать Event Storming на практике? Приглашаем вас на воркшоп:
«Event Storming как техника моделирования предметной области и выявления микросервисов»
На воркшопе вы получите:
— Опыт моделирования предметной области и выделения микросервисов
— Полезные материалы
— Детальный разбор Big Picture, Process Modeling, а также System Design
— Сертификат о прохождении воркшопа
Регистрация
Когда бизнес, аналитики и разработчики говорят на разных языках, результат всегда один — задержки, ошибки и потерянные ресурсы.
Если часто слышите от бизнеса: «Мы же это не так представляли»? Или от разработчиков: «А почему нам это раньше не сказали?» — это говорит о классических симптомах проблем с пониманием и коммуникацией.
Существует решение, способное навести порядок и выстроить эффективную коммуникацию. Это Event Storming — признанная техника, предназначенная для синхронизации всех элементов проекта. Она позволяет визуализировать процессы автоматизации, улучшения бизнеса, выявлять скрытые проблемы и формировать общее понимание среди всех участников.
Event Storming — это метод совместного моделирования, который вовлекает в процесс всех заинтересованных лиц, от разработчиков до представителей бизнеса. Благодаря визуализации бизнес-процессов и выявлению ключевых событий, формируется целостное представление о системе и ее потребностях.
Хотите научиться использовать Event Storming на практике? Приглашаем вас на воркшоп:
«Event Storming как техника моделирования предметной области и выявления микросервисов»
На воркшопе вы получите:
— Опыт моделирования предметной области и выделения микросервисов
— Полезные материалы
— Детальный разбор Big Picture, Process Modeling, а также System Design
— Сертификат о прохождении воркшопа
Регистрация
systems.education
■ Онлайн-воркшоп. Event Storming как техника моделирования предметной области и выявления микросервисов
Будет полезен системным аналитикам и начинающим архитекторам, которые хотят научиться быстрому исследованию бизнес-процессов, изучить технику моделирования предметной области, выделять микросервисы
Какие существуют этапы и участники в процессе выявления требований к информационной безопасности (ИБ)?
Определить угрозы ИБ, чтобы выявить необходимые требований к ИБ и минимизировать возможные риски, помогает риск-ориентированный подход. Его основные этапы и участники:
Этап 1: Определение защищаемой информации
🔧 Что делаем: Определяем, какие данные обрабатывает система, их ценность и возможные последствия их компрометации.
👤 Кого привлекаем: Владелец продукта, юристы, бизнес-аналитик, специалисты по ИБ, руководители бизнес-подразделений.
Этап 2: Анализ архитектуры системы и границ доверия
🔧 Что делаем: Определяем, как передаются, обрабатываются и хранятся данные, какие компоненты системы взаимодействуют друг с другом.
👤 Кого привлекаем: Архитектор системы, системные администраторы, сетевые инженеры, системный аналитик.
Этап 3: Определение потенциальных злоумышленников
🔧 Что делаем: Классифицируем угрозы: внешние (хакеры, конкуренты) и внутренние (инсайдеры, недобросовестные сотрудники).
👤 Кого привлекаем: Специалисты по ИБ, служба безопасности, HR, юристы.
Этап 4: Выявление уязвимостей и угроз
🔧 Что делаем: Анализируем слабые места системы и возможные сценарии атак.
👤 Кого привлекаем: Application Security инженеры, архитекторы безопасности, тестировщики, разработчики, администраторы баз данных.
Этап 5: Оценка рисков
🔧 Что делаем: Определяем вероятность наступления угроз и возможный ущерб.
👤 Кого привлекаем: Руководители подразделений, специалисты по рискам, финансовые аналитики.
Этап 6: Формирование требований к ИБ
🔧 Что делаем: Определяем меры защиты, учитывая приоритеты и бизнес-ограничения.
👤 Кого привлекаем: Системный аналитик, архитекторы системы, специалисты по ИБ, DevOps-инженеры.
Важно! Процесс выявления требований к ИБ не разовый — он должен регулярно пересматриваться при изменениях в бизнесе, законодательстве или ИТ-инфраструктуре. Об этом более подробно расскажем в следующем посте.
Все эти этапы мы детально разбираем на воркшопе «Основы разработки требований к информационной безопасности ИТ-систем». Практика проходит под руководством эксперта, который поделится своим опытом и покажет какие инструменты аналитики могут использовать для этого!
Регистрация
Определить угрозы ИБ, чтобы выявить необходимые требований к ИБ и минимизировать возможные риски, помогает риск-ориентированный подход. Его основные этапы и участники:
Этап 1: Определение защищаемой информации
🔧 Что делаем: Определяем, какие данные обрабатывает система, их ценность и возможные последствия их компрометации.
👤 Кого привлекаем: Владелец продукта, юристы, бизнес-аналитик, специалисты по ИБ, руководители бизнес-подразделений.
Этап 2: Анализ архитектуры системы и границ доверия
🔧 Что делаем: Определяем, как передаются, обрабатываются и хранятся данные, какие компоненты системы взаимодействуют друг с другом.
👤 Кого привлекаем: Архитектор системы, системные администраторы, сетевые инженеры, системный аналитик.
Этап 3: Определение потенциальных злоумышленников
🔧 Что делаем: Классифицируем угрозы: внешние (хакеры, конкуренты) и внутренние (инсайдеры, недобросовестные сотрудники).
👤 Кого привлекаем: Специалисты по ИБ, служба безопасности, HR, юристы.
Этап 4: Выявление уязвимостей и угроз
🔧 Что делаем: Анализируем слабые места системы и возможные сценарии атак.
👤 Кого привлекаем: Application Security инженеры, архитекторы безопасности, тестировщики, разработчики, администраторы баз данных.
Этап 5: Оценка рисков
🔧 Что делаем: Определяем вероятность наступления угроз и возможный ущерб.
👤 Кого привлекаем: Руководители подразделений, специалисты по рискам, финансовые аналитики.
Этап 6: Формирование требований к ИБ
🔧 Что делаем: Определяем меры защиты, учитывая приоритеты и бизнес-ограничения.
👤 Кого привлекаем: Системный аналитик, архитекторы системы, специалисты по ИБ, DevOps-инженеры.
Важно! Процесс выявления требований к ИБ не разовый — он должен регулярно пересматриваться при изменениях в бизнесе, законодательстве или ИТ-инфраструктуре. Об этом более подробно расскажем в следующем посте.
Все эти этапы мы детально разбираем на воркшопе «Основы разработки требований к информационной безопасности ИТ-систем». Практика проходит под руководством эксперта, который поделится своим опытом и покажет какие инструменты аналитики могут использовать для этого!
Регистрация
👍4❤3