Event Storming

Вот так Notebooklm сжал теорию первого дня корп курса по Event Storming, очень хорошо сжал, я бы сказал. Никакой лишней информации нет, так что можно выложить :)

Темпоральность в Event Storming

Вчера обсуждали с Геной Кругловым темпоральность в Event Storning, а сегодня выступал перед участниками IN HUB с темой «Картина производственной системы за часы» (домен промышленного производства и смежных отраслей) и был у меня в презентации такой слайд и вчерашнее обсуждение и сегодняшнее выступление привели к новым мыслям.

Так вот, на этом слайде сразу четыре темпоральности (авторская интерпретация и она может измениться):

▪️Хаос (Chaotic Exploration)
Здесь только темпоральность события как высказывания с точки зрения семантики (по модели Рейхенбаха). События концептуально относены ко времени.

▪️Хронология (timeline enforcement)
Это интерсубъективно разделяемая хронология. Ключевой смысл в том, что здесь появляется темпоральность модели как структуры. В самой структуре появляется отношение порядка. Однако, пока только порядка (раньше/позже) и это важно.

▪️Контекст (обогащение модели, в первую очередь через Policy в рассматриваемом контексте)
В хронологии появляется своего рода реактивная темпоральность. На самом деле это кусочки реактивной темпоральности. Политики позволяют отличить автоматизированную реактивность от человеческой и вводят критерий верификации модели: Почему эта команда выполняется? При каких условиях? Всегда ли? Отсутствие явных политик делает причинно-следственные связи неявными и модель теряет способность отвечать на вопросы «Почему?» и «В каком случае/когда?»

▪️История (Narrative / Reverse Narrative)
А здесь самое интересное. Это нарративная темпоральность (Paul Ricoeur, Джером Брунер), история, общий нарратив, обеспечивает переход от «позже - не значит вследствие» к «это вследствие вот этого». Это усиление темпоральности модели причинно-следственными связями.

А теперь прикладной вывод: если мы можем построить согласованную историю, построенную полностью на основе реактивной автоматизированной темпоральности (между каждым событием и командой поставить Policy), то мы можем с большей степенью уверенности говорить, что описанный процесс может быть реализован с помощью автономного ИИ-агента или мультиагентной системы.

Однако на текущий момент требуется больше наработок, потому что:
▪️Не факт, что агенты способны интерпретировать все типы Policy
▪️Человеческий контекст и неформализуемые аспекты могут оказать существенное влияние
▪️Техническая реализуемость не следует прямо из концептуальной полноты модели

Формирование рабочей группы по разработке методологии «Стратегического Event Storming»

На выходных меня не отпускала мысль, что что-то есть в предложении Юрия Куприянова интегрировать форсайт и Event Storming. Ведь фактически форсайт – это и есть варианты продолжения цепочек событий, но в будущее, а стратегическая сессия – это ограниченитель, фильтр для отбора вариантов.

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

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

Интересно, что подобного использования Event Storming практически нет в публичных материалах в международной практике – метод остается преимущественно в пространстве технического проектирования.

Мы можем стать первыми, кто систематизирует этот подход и сделает его воспроизводимым инструментом!

Что будем делать
- Систематизируем опыт
- Создадим методологическую базу
- Подготовим к публикации
- Протестируем

Временные затраты
5-15 часов в неделю в течение 3 месяцев (февраль - апрель)

Что получите
- Соавторство
- Опыт создания воспроизводимого метода с нуля
- Новые связи среди единомышленников
- Возможность применять результаты в своей практике
- Что-то свое :)

Сам я это воспринимаю как создание чего-то значимого, что будет использоваться другими в том или ином виде. Если вы готовы к серьезной работе с амбициозной целью – буду рад видеть вас в команде.

📝 Ссылка на анкету для подачи заявки на участие (будет отбор):
https://forms.gle/WFSX6akDVA6NLqgY7

Дедлайн подачи заявок: 16 января 2026
Отбор и формирование рабочей группы: 16 января - 23 января
Kick-off встреча: на неделе с 26 по 30 января

PS: если знаете кого-то, кому может быть интересно, перешлите это сообщение :)

Ответ к заданию

1. Не нужно выбирать единый свимлейн на всю модель
2. Вход в модель по каналам (свои события входа, своя модель подтверждения личности, свой UX)
3. После того, как определено намерение клиента (это может быть проблема, информация) - канал перестает иметь значение.
4. После того, как определено, что нужно сделать, в игру вступают продукты – они обозначаются как системы, так как по отношению к предметной области поддержки клиентов они и являются внешними системами.

Почему нет свимлейнов по типам клиентов (vip, …)?
Тип клиента - это атрибут, а не процесс. Если выделить в отдельный свимлейн, то 90% событий будут дублироваться. Здесь как раз нужны политики (Policy) маршрутизации по типу клиента.

Почему нет свимлейнов по продукту?
Клиент живет в проблеме, а не продукте, а продукты – вообще внешние по отношению к рассматриваемой предметной области. Проблема «не прошла оплата» может относиться к множеству продуктов.

Разомнемся на выходных? :)

Ситуация с которой вы столкнетесь не раз и не два.


Итак, представьте. Вы проводите Event Storming в службе поддержки клиентов.
Служба поддержки использует 7 каналов взаимодействия с клиентами (телефон, чат, почта, …), клиенты бывают 3 разных типов (vip, обычный+, обычный), количество продуктов на поддержке - 50+.

Структуру можно организовать разными способами (слева направо, см пример на картирнке):
- Свимлейны с каналами, и для каждого канала свимлейны с продуктами
- Свимлейны с продуктами, и для каждого канала внутри свимлейны с каналами
- Глобальные свимлейны для типов клиентов, внутри свимлейны для продуктов, внутри продуктов - свимлейны для каналов
- …
- и еще 11 способов (в том числе с только одним или вообще без свимлейнов)

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

Вопрос: как бы вы визуализировали такую структуру и почему?

UPD_1: Денис задал хороший вопрос: «смотря для чего проводим». Это очень правильный вопрос, так как Event Storming – лишь инструмент. Проводим для того, чтобы исследовать предметную область и из текущей реализации вынести специфичную для продуктов логику, тем самым защитив реализацию платформы поддержки от попадания элементов предметной области конкретных продуктов. То есть, чтобы сопоставить модель предметной области и модель текущей реалзации и выявить расхождения.

👆максимально полезно для Event Storming

Наступает время личных и корпоративных стратегических выборов

Стратегический выбор стоит начинать не с выбора решений, а с тщательного исследования Problem Space – что именно является проблемой, для кого и почему это вообще проблема. В связи с этим – полезный материал по изучению проблемы и выбора типов решений (полагаю, Тарасенко для большинства подписчиков моего канала – вовсе не новая фамилия, а для кого новая – рекомендую его работы).

Отдельно добавлю про технологическую стратегию.
Для нее это означает, что «правильность» выбора направления развития нельзя обсуждать в вакууме. Необходимо явно перечислить стейкхолдеров, их интересы и критерии (качество, риски, скорость, стоимость, комплаенс, …), потому что именно в Problem Space формируются ограничения и критерии будущих решений. Сама идея «улучшающего вмешательства» (никому не хуже, кому-то лучше) полезна как граница для технологических инициатив, то есть хорошая стратегия должна улучшать положение целевых групп и не создавать новых проблем для остальных (безопасность/эксплуатация/финансы/…).

Это очень полезные 16 страниц 🚀

Фокус проведения Event Storming

В четвертом квартале у меня сильно сместился фокус проведения сессий Event Storming. Причем, не постепенно, а достаточно резко. Проведено много сессий в рамках стратегический сессий, на которых Event Storming выступал как метод формирования общего представления о текущей реальности для того, чтобы сонаправить участников стратегических сессий.

Интересно и то, что я не вижу подобного использования Event Storming в международных статьях и выступлениях. Как-будто мы снова проигрываем в международном PR, но при этом развиваем подходы достаточно активно и динамично.

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

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

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

Приведу пример (из прошлого):
Ратифицировано Парижское соглашение по климату (внешнее)
Федеральный закон «Об ограничении выбросов парниковых газов» вступил в силу (внешнее)
Принято обязательство о достижении углеродной нейтральности операционной деятельности (внутреннее)

Паттерн:
Международное обязательство страны -> Национальное законодательство -> Корпоративная стратегия

Продолжение про «похожие процессы» и про важность DDD.

(кажется, получился очень глубокий и важный пост про важность DDD)

Конкретным профессиям и их внутренней кухне (туризму, логистике, финансам, медицине) в профильных вузах учат годами. Для тех, кто прошел такой путь, типовые процессы внутри их отрасли выглядят очень похожими: одни и те же шаги, одни и те же риски, одни и те же точки принятия решений. Но есть один нюанс…

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

И вот спец по туризму открывает турфирму. Нанимает сотрудников, поднимает продажи, строит партнерства – бизнес как‑то работает.

В какой‑то момент становится тесно в Excel и мессенджерах и он нанимает разработчиков: «пора автоматизировать».
Что разработчик, который 5 лет учился на разработчика, знает о туризме? Ну… есть Турция, Египет, самолетом можно долететь, отели бывают с завтраком и без….

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

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

Со временем разработчик, конечно, начинает лучше понимать процесс, картинка становится целостнее…. но к этому моменту система уже обросла заплатками так, что ее страшно трогать. «Сначала требования определяют архитектуру, а затем живут в ней» (c) мой

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

С должным усилием, упорством и желанием этот разработчик вырастает до архитектора.
Он наконец смотрит на весь процесс целиком и понимает, что 90% кода можно выбросить и заменить несколькими коробочными продуктами, одним внешним сервисом и небольшим слоем кастома. Потому что реально уникальное – вот эти самые 5%, где и прячется конкурентное преимущество бизнеса, а все остальное – типовой, стандартный Generic.

Вот эту проблему во многом и решает DDD вместе с практиками вроде Event Storming.
Они как раз про то, как вытащить знание экспертов (в нашем примере – гуру в туризме), перевести его в общий язык и донести до разработчиков и архитекторов так, чтобы все видели одну и ту же цельную картину.

Пока этого понимания нет, «в прод идут лишь предположения разработчиков о предметной области» (c) Альберто Брандолини
Как только оно появляется – архитектура начинает работать на бизнес, а не наоборот.

Публичный кейс :)

https://scrumtrek.ru/cases/eventstorming-v-ecom-tech/

Это из видео про цунами, кому интересно, отсюда - https://www.youtube.com/watch?v=lTxfNHx93hI&t=2203s

:)

Вот тут Event Storming и DDD практически вне конкуренции в части эффективности, причем это индустриально подтвержденные подходы.

По просьбам подписчиков попробую пересказать предыдущий пост простыми словами.

Онтология отражает язык вашей предметной области, на котором вы разговариваете каждый день в своей работе.

Этот язык не нужно придумывать — его нужно «вытащить на поверхность» и оцифровать.

Когда вы создаёте онтологию, вы формализуете этот язык, чтобы его одинаково понимали и вы, и ваши коллеги, и машины.

В процессе создания онтологии вы и другие эксперты договариваетесь о терминах и делаете неявные знания явными.

Одновременно вы создаёте и «скелет» знаний для LLM — основу, на которую модель сможет опираться при решении ваших задач.

LLM прекрасно натренированы на синтаксисе формальных онтологий (например, Turtle) и хорошо его понимают.

Передавая онтологию в контекст LLM через промпт (in-context learning), вы выполняете «заземление» рассуждений модели (grounding) и резко снижаете вероятность галлюцинаций.

Модель буквально начинает говорить на вашем языке.

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

А дальше — всего один шаг, чтобы начать разговаривать с вашими данными в графовой БД на вашем языке.

Отдельный вызов — научиться фреймить контексты, чтобы не перегружать LLM и управлять её вниманием. То есть не просто передавать в модель всю онтологию, а динамически собирать из неё релевантные подграфы — «подъязыки», соответствующие конкретным задачам.

О многом из сказанного в этом тексте я уже писал в своих предыдущих постах — и пытливый ум при желании мог воссоздать эту «картину» ещё несколько месяцев назад.

🗓️ Вебинар 30 октября в 19:00
Ведущий: Сергей Баранов

Модульность без фанатизма: о чем на самом деле книга Balancing Coupling

Встречаемся с Владом Хононовым — архитектором и автором книг «Learning Domain-Driven Design» и «Balancing Coupling in Software Design». Именно об идеях из второй книги мы и поговорим.

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

Разберем модель Strength–Distance–Volatility и покажем, как применять эти принципы при проектировании устойчивых распределенных систем. 🚀

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

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

👉 Регистрация по ссылке

Напишите в комментариях о чем было бы интересно почитать, о каких проблемах или что непонятно и стоит разобрать, а то судя по реакциям, последние сообщения не вызывают особого интереса 🙂

Примеры аспектов обсуждения в зависимости от целей проведения самих сессий (не бизнес-целей компании). Это к тому, вокруг чего строить фокусную структуру самой сессии. Это не значит, что в рамках конкретной цели не важные иные аспекты, это означает, что должно быть в центре внимания, а остальное – дополнение к основным аспектам исследования.

Еще более простая конструкция сбора метаинформации.

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

Это к пункту «Заготовить инструменты для сбора обратной связи об уровне энергии участников (для онлайна, так как людей не видно)»